技術士二次試験 午後３

 午後３は、何と両方の問題がＡＩ！！　時代はＡＩか。(´・ω・`)

しかし弊社ではAIが解禁されていないので、僕には逆風である。とは言え、仮に解禁されていたとしても、どこまで論文執筆の作成の手助けになるかは懐疑的。

と言うのも、世の中の人がAIを活用していると言っても、まさかAIを前提したシステムをゼロから構築するなんてゴージャスな経験を持っている人は滅多にいないはず。精々が、手作業でやってた実装をAIに手伝ってもらうとか、そういうチンケな活用ではないか。

そういうチンケなAI活用を以て「これがAIの活用法だ！！」とホザく。そんなんじゃ論文にならんわ。

この問題は、現実的には出会えないような遠大なプロジェクト観を述べるべきもの。僕はAI自体は作業経験が少ないが、プロジェクト観なら行けるはずだから、そこで勝負する。

午後Ⅲー１

AI駆動開発において、品質確保と管理の在り方について述べよ。

（１）多面的な観点からの課題

生成AIをプロジェクトに持ち込むとしたら、その観点は４つあると思う。

• 設計者の観点。設計に生成AIを使う
• 実装者の観点。実装に生成AIを使う
• テスターの観点。テストに生成AIを使う
• マネージャーの観点。生成AIと言っても色々あるでしょう。どの生成AIを導入するのが最も妥当であるかをどうやって決めるのか

僕は「実装」「テスト」「マネージャー」の３つを選んだ。

（２）最も重要な課題と対策

このうち「実装」が一番重要だと思う。やっぱり生成AIと言ったらコード生成AIが花形でしょう。そもそも僕自身がプログラマーだから、ソースに関するものじゃないと書けないしね。

• マイクロサービスアーキテクチャ。僕の切り札。生成AIって、従来型のモノシリックな巨大ソースの全部をAIに食わせたら何が起きるか分からん。でも、マイクロサービスならその単位に限られる。生成AIの大暴走デグレード祭りを抑止するには、そもそもの設計方針がマイクロサービスであることが理想像のはずだ
• テスト駆動開発。まあこれはお約束と言うか、常識レベルか。先にテストソースを書いて、後から本体ソースを作る。そうすれば本体ソースの中身がどうなろうが、テストがＯＫであれば安心でしょ？　ただし、テストソースばかりはプログラマーがレビューしなければならん。そこが人間の責任だからね
• 検査ツールの有効活用。AIが生成したソースに対し、静的テストツールを実行する。それで変なのが見つかれば直せるっしょ。あと、脆弱性診断ツールを実行する、とか。SBOMを実行する、とか。こういうツールを使えばAIが変なソースを作っても見つけられる。

（３）すべての解決策を実行しても新たに生じる将来的な懸念事項

これが苦手な問題でね。「新たに生じる将来的な懸念事項」は、（２）の内容ならではの懸念事項じゃないといけないのよ。

例えば、「生成AIって急に性能が悪くなることあるのが心配」とか。それは（２）がどんな内容であろうが、生成AIを使っている時点で必ず発生する。そういうのはＮＧ。「（２）の内容だからこそこんな問題が起きるかも」という内容でなければいけない。

これが苦手で。どうしてもＮＧパターンを踏んでしまう。生成ＡＩの懸念事項なんてパターンが知れてると思うのだが。

それでも何とかひねり出したアイデアがこれ。

• 可用性の低下。（２）の対策をやっても、やっぱり障害はどこかで起きるもの。しかし、AIに頼り切った怠惰なプログラマー集団に、障害発生時の対応能力があるだろうか？　（２）の対策が人間の能力を下げるのではないか？　結果として障害からの復旧が遅い、みたいなことが起きることが懸念事項である

で、対策は、綺麗なストーリーが思いつかなかったから、「複合的な対策を行う」と称して知ってる限りの技術情報を詰め込みまくった。(；´^ω^`)

• いざという時にソースが読めるよう、コーディング規約を用意しろ。コード生成AIは毎回の実行時に必ず固定ファイルを読み込む設定が可能だから、そこにコーディング規約を書く。改善活動も行う。
• 生成ＡＩをもう一個用意しろ。障害発生時に、第一の生成ＡＩでは原因を特定できずとも、第二の生成ＡＩなら見つけてくれることもある。
• バグが見つかったら並行展開しろ。生成AIは「観点」を絞れば精度が上がるから、障害の内容を元に観点を作って、その観点で並行展開を行えば、上々な精度で同じ種類のバグを見つけてくれるはずだ
• 最後に、人間の努力。定期的に技術交流を行い、そこで得た知見を開発標準にフィードバック。そういう地道なPDCAを回すことも大事なんやで

こう書いた。

あ～、でも、今気づいたんだけど、「生成ＡＩを２コ使う」は、そもそも（２）の段階で導入しておくべきだったか？

世間の皆さんってどうやってるの？　ＡＩ二刀流って凄く贅沢っしょ。そりゃ複数使って片方を開発用、片方を評価用にすることで客観性が得られる、という理屈は分かるけど。

でも、生成AIって自分で作ったソースを他人事みたいに話すじゃん？

「お前が作ったソースをお前がレビューしろ」

「はい。改善点が見つかりました！！」

ふざけんなっちゅ～の。こんなんだったら自己レビュープロンプトを３回回せば良い。別のＡＩを持って来れば品質が上がるとか、それは理想論じゃなくて現実的に本当なのかね？

僕は本業でＡＩを使っていないから、どうしてもこういう現場知識に劣る。厳しい境遇である。(´・ω・`)

終わりに

さてさて、今年も地獄の試験を終えたわけだが、何度も受験しているだけあって、コツは掴めてきている感じがするな。

それでも合格しないのは、そもそも知らんもんは知らんからだろう。だって、そんな経験無いもん。夢と妄想で論文書いてる。

そこを勉強と技術研鑽で克服しなければいけないんだろうけど、そこで問題になるのが、ＡＩの高額ぶり。個人の勉強でＡＩを使うのは高額過ぎるし、そもそもちょっと命令してソースを作ってみた、みたいなチンケな話を知りたいわけじゃない。

プロジェクトとしてＡＩを採用するという本格的な業務経験が必要なところ、僕にはそれが無い。

しんどい時代になったもんじゃわい。(´・ω・`)