【前編】世界一流 ✕ コード ✕ AI – AI時代のエンジニア思考法を探る！
本記事は 2024/10/08 に開催されたイベント「世界一流 ✕ コード ✕ AI – AI時代のエンジニア思考法を探る！」の内容をもとに執筆されました。
「コード×AI ー ソフトウェア開発者のための生成AI実践勉強会」(以後「コードAI本」)の著者である服部佑樹と、「世界一流エンジニアの思考法」を執筆された牛尾剛さんが、AI時代のエンジニア思考法について対談しました。（以降敬称略）
本記事は二部構成のうちの前編となります。
AIツールの実践的な活用法
服部：今日は実践的なAIの活用法について、特に一流エンジニアの現場でどう使われているのか、深掘りしていきたいと思います。まず率直に伺いたいのですが、牛尾さんはAIをどの程度活用されていますか？
牛尾：もう完全にゴリゴリ使ってますよ（笑）。時には痛い目に遭うこともありますが。
服部：具体的にはどんな使い方が多いんでしょうか？
牛尾：一番よく使うのは、やっぱりGitHub Copilotですね。コードを書こうとすると「たぶんこういうコードが欲しいんでしょ？」って提案してくれる。そのサジェストが本当に的確で「その通り！」ってなることが多いんです。
でも、私にとって特に重要なのは英語周りのサポートですね。私、日本にいた頃は「英語が上手い」って言われてたんですよ。でも、アメリカに来たら…まあ、単なる「英語下手くそ」ですよ（笑）。
服部：その経験は非常にわかります… 英語のネイティブスピーカーと働く中で、具体的にどんな課題に直面されたんですか？
牛尾：変数名やメソッド名、ログの文字列なんかで苦労しましたね。レビューでも指摘されがち。というのも、「良いネーミング」って単なる文法や単語の知識だけじゃないんですよ。すごく微妙なニュアンスが必要で。でも、AIはそこが得意なんです。
例えば、自分で趣味のアプリを作るときなんかも、プロジェクト名全部AIに考えてもらってます。「こういう責務を持ったクラスを作りたいんだけど、いい名前ない？」みたいな感じで相談するんです。
服部：なるほど。ちなみにMicrosoftの中、特にAzure Functionsチームでの命名規則はどうなってるんですか？最近のAIは、かなり記述的で詳細な変数名を提案してくれますよね。
牛尾：実は、チームの厳密な命名規則というのはないんですよ。むしろコンテキストが重要で、「周りがこうなってるから合わせよう」くらいの感覚です。面白いのは、AIが自然とある程度の制約の中で提案してくれること。本当に必要な部分は勝手にやってくれるので、プログラマーとしてはそこまで意識しなくていい。
それより大事なのは、他の人が見たときに「わかりやすい」と感じるネーミングですね。そこは人間の判断が必要な部分かもしれません。
服部：AIツールを使いこなしながらも、最終的な判断は人間が行う。そのバランス感覚が重要だということですね。
牛尾：そうですね。AIは強力な助手ですが、あくまでツールです。私たちエンジニアの「意図」や「目的」を理解した上で使うことが大切です。特に命名のような、コードの可読性に直結する部分では、AIの提案をベースにしつつも、人間が最終判断を下す必要があります。
服部：その辺りの判断力こそが、これからのエンジニアに求められる重要なスキルになりそうですね。
AIとの協働に適したコード設計とは
服部：最近のAIツールの進化は目覚ましいものがありますが、チーム開発の文脈でAIと上手く協働していくには、どういったコード設計が望ましいとお考えですか？
牛尾：そうですね。例えばMicrosoftのAzure Functionsのようなマイクロサービス環境では、コードベースが非常に大きくなりがちです。そうなると、AIにコード全体のコンテキストを理解させるのが難しくなってきます。
服部： AIのコンテキストウィンドウには限界がありますからね。そうなると、コードの分割や関心の分離がより重要になってきそうですね。実際には、AIとの協働を意識することで、従来のベストプラクティスがより重要になってきているんです。例えば、コードの分離をきちんとやっておくと、AIによるコードレビューの精度も上がりますし、コメントの付与なども効率的になります。
牛尾：そうですね。インデントの付け方一つとっても、最近のAIは結構賢くなってきていて、適切なサジェストをしてくれるようになりました。以前はそこまで賢くなかったんですが、今では文脈を理解したより自然なコードの提案をしてくれます。
服部：コードの一貫性という観点では、どうお考えですか？特に、長年運用されているプロジェクトでは、時代によって適切なコードの書き方も変わってきますよね。
牛尾：そうなんです。例えばC#なんかは、どんどん新しい機能が追加されていって、現代的な書き方が可能になっています。ただ、古いコードベースでは使えなかった機能も多いわけです。なので、完全な統一性を求めるのは現実的ではないんですよ。
服部：では、チーム内でのコードの一貫性はどう担保されているんでしょうか？
牛尾：私たちの場合、厳密なルールは設けていないんです。代わりに、プルリクエストのレビュー時に、コードの読みやすさを重点的にチェックしています。結局のところ、他の開発者が理解しやすいかどうかが一番重要なんです。
服部：AIとの協働という観点では、ちゃんとAIの癖を理解しておくことも重要なんでしょうね。 時々嘘をつくし、与えられた命令を無視することもある。文脈を完全に理解していないこともよくあります。だからこそ、コードを適切なサイズに分割して、AIが扱いやすい単位にすることが重要です。
牛尾さんのほうで具体的なAIのユースケースのおすすめは領域はありますか？
牛尾：ベンチマークのコード生成なんかは、AIが得意とする領域の一つですね。これまでは面倒くさがって後回しにしがちだった作業も、AIを使えば効率的に実装できます。
服部：いいですね。これまでの話だと、やはりAIの特性を理解した上で、それに合わせて活用方法を模索していく必要がありそうですね。 AIとの共同を考えると、結果的に人間にとっても理解しやすく、メンテナンスしやすいコードになっていきますよね。私がコードAI本で書いたことはまさにそのことなんです。AIとの協働を意識することで、より良いコード設計の実践につながっているというわけです。
今つくっている個人開発アプリからの学び
服部：今取り組んでいるプロジェクトについて教えていただけますか？
牛尾：面白いプロジェクトに取り組んでいるんですよ。Microsoftのサービスグループで、世界中から上がってくるインシデント対応の自動化に挑戦しています。特に複雑で開発チームでないと解決できないような案件を扱うんですが、正直なところ、これをAIに任せられないかなと考えているんです。
服部：なるほど。日々の業務で感じる課題から生まれたアイデアなんですね。
牛尾：そうなんです。例えば、私の専門分野に関する質問が毎日のように集中してくるんですよ。これをAIに任せられれば、もっと高度な仕事に時間を使えるんじゃないかと。特に気づいたのが、Kusto Queryを使った調査作業なんですが、インシデントごとに違う対応が必要でも、根底にあるメンタルモデルは実は同じなんです。
服部：Kusto Queryというのは、MicrosoftのSQL-likeなログクエリ言語ですよね。
牛尾：その通りです。例えば「このテーブルをクエリして、こういう結果が出たらこっちを調べる」というような流れ。個々のケースで違いはあるんですが、大きな思考の道筋は似ているんです。これをAIに任せられないかと。
服部：でも、そういったクエリをAIに扱わせるとなると、トークン数の制限とか色々な課題がありそうですね。クラウド製品のログを考えると、考えるべきテーブルが膨大すぎて、AIがそれを全て理解するのは難しいかもしれません。
牛尾：最初は本当に苦労しましたよ。簡単なものはすぐできるんですが、それを安定させるのが一番の課題でした。トークン数が増えると、AIが嘘をつき始めるんです。何回か実行してうまくいったと思っても、次は全然違う結果が返ってきたり。
服部：その課題をどのように解決されたんですか？
牛尾：アーキテクチャで解決しました。例えば、複数のステップに分割して実行するようにしたんです。実際の現場では、使うカラムやパターンって意外と限られているんですよ。そこに着目して、ファンクションコーリングのような形で、パターンごとに処理を分けました。
プレーンテキストからAIにwell-formedなJSONを生成させ、それをソースジェネレータでコードに変換したり。プロンプトもDSLを作ってワークフローにして、各ステップ間でトークン数を最小限に抑えるような工夫をしています。
服部：なるほど。AIの出力を完全に信頼するのではなく、人間が検証できる形で結果を表示する仕組みも入れているんですね。
牛尾：そうなんです。AIが嘘をつく可能性も考慮して、各ステップの実行結果を表示するようにしています。完璧じゃなくても、インシデント調査の助けにはすごくなるんです。AIが調査している間に他の仕事ができますし、出てきた結果やクエリを参考に、人間がさらに考察を深められる。それだけでも十分価値があると感じています。
AIとの協働について書いたコードAI本は好評につき重版決定。
そして牛尾さんの「世界一流エンジニアの思考法」も絶賛発売中です。
AI時代のエンジニア思考法について、さらに深く学びたい方は、ぜひ両書をお手に取ってみてください！
