2026年時点におけるAIエージェントへの向き合い方

前提として

そもそもだが、LLMの適用範囲だとかレビューの有無だとかの話になると一律それを適用したがる言葉足らずな人が多いけれど、実際はもっとグラデーションがあって、状況や場合に依ると思う。

例えばUIの検証をするためにプロトタイプが必要なら、なるべく早く試してフィードバックを得るのが目的だからLLMで生成すればいい。個人で使うツールなど壊れても影響が小さいコードもLLMで困らないだろうと思う。本番サービスでも単にDBをCRUDするだけの機能なら、何かあったところですぐに修正できるからそれでいい。

しかしユーザー数の多いサービスのコアとなる機能であったりとか、課金処理やデータベーススキーマの定義、お金や人命がかかわる場所のコードは慎重になった方がいいだろう。もちろん人間は間違えるものだが、人間がドメインやコードの知識を持っておかなければ意図しない動作をしたときの原因究明や解決で困ることになる。

過激な論への反応

AIエージェントの発展によって人間は仕様を書くだけになるという論は、そういう割合は増えると思うけれど、個人的にはそうならないと思っている。過去にSIer等では、社内では仕様を書いてコードを外注するという文化があった。それと比べると往復のやり取りも早いし、言いづらいことでも言えるようになっているのだから同じことにはならない論はあるが、問題はそれをすると仕様を書く側の知識がそこで止まってしまって、結果的に歪なコードが生産されていく。経験の切り売りという言葉が近いかもしれない。

LLMとコンパイラは比較するべきではない。コンパイラは、バグで壊れる可能性はあるが、長期的にみれば高級言語で書いた意図通りに動くことが担保される。しかしLLMはそうではなく、自然言語という曖昧なものを使って確率論的に生成するので、元の意図通りに動く保証はない。

AIによるコード出力への信頼は、コンパイラではなくSaaSと比較するべきではないか

コードレビューについても同様に、10年前はレビューをしない環境がいくつもあったけれど、

属人性の排除
ミスの検出
コード品質の向上
教育的価値

などを目的としてレビューの文化が入ってきたので、「そこで律速するから」という理由だけでレビューをなくしてもワークはするだろうが以前の状態に戻ってしまう。コードレビューの目的にもいくつか話題がある。

ハーネスを整える

Mitchell Hashimoto氏の記事から発展した話？で、まず自分で書いて、同じコードを生成するようにAIエージェントのスキル等を調整する手法をハーネスエンジニアリングと呼ぶらしい。

こういったガードレールを整えて、LLMの出力をコントロールするのだが、では理想の状態は誰がどこで整えるのだろうか。開発が進むにつれてドメインの知識が増えていくので、それを理想の状態へ反映するのはどうするのか。全てをLLMで生成したとき、どのくらいのドメイン知識が得られるのかは分からない。

手でコードを書く価値

実体験として、LLMが生成したコードをしっかり見ていたつもりでも、絶対に自分では書かないコードを見落としていて愕然としたことがある。もう詳細は覚えていないが、例えばGoのコードを書いているとき

import "golang.org/x/exp/slices"

slices.SortFunc(a, fn)

というコードが生成されたのなら、現在は標準ライブラリに同等の関数が実装されているので間違いなく標準ライブラリへ切り替えると思うけれど、全く気づかずにコミットしてしまっていた、という雰囲気の事例があった。

同様の事例で、翻訳本のレビューをするため本を読むときは、普段の生活で本を読む場合と比べて何倍も疲労するし時間もかかるという体感がある。この原因は、レビューのために読むときは一字一句間違えがないかを確認しながら読むのだけれど、普段はある程度、前後の文章を推測して読んでいるという違いによって起きるのだろう。上で挙げたコードの事例も「標準ライブラリの slices が使われるだろう」と推測して読んだのだろうと思う。そもそも x/exp/slices の存在自体を忘れていたのもあるかもしれないが。

具体例は他にも色々あるが、詳しくはコードを書いていると良い方法を思いつく事例でまとめる。

だから意識としては「読んでいる」つもりでも、実際は一部しか読めていない。これが書く場合となると、強制的に一字一句すべてを意識することになるので、読むと書くでは得られる情報量が全く違っている。書くことで脳が整理されるとい理由もあるだろう。だから人間が思考を整理したり学習したりといった活動をするためには、書くということは失ってはいけないと思う。