生成AI

AIは嘘をつく。でも本当に危険なのはそこじゃない。

生成AIを使って比較的大きなプログラムを作る際に見えてきた課題。 生成AIに大きなプログラム作成を頼む時に最初の頃は、 - AIに設計させる - AIに実装させる - 「次へ」と入力する を繰り返していました。しかし結果として、 - 特定のクラスだけ異常に肥大化 - ヒューリスティック地獄 - ｉｆ文だらけ - 保守不能 という、あまり嬉しくない状態になりました。 しかも有料クレジットを大量消費した割に、完成したアプリは期待以下。。。 その経験から、 「AIの設計能力・レビュー能力」と「AIのコーディング能力」は分けて考えるべきではないか？ と思うようになりました。現在は、 ``` 人間 ↓ AIマネージャー（設計・レビュー） ↓ AIコーダー（実装） ``` という形で使っています。 この方式にしてから、大規模開発の成功率がかなり上がったと思います。 --- # AIの課題を整理してみる 議論を続ける中で、AIの課題は大きく - システム課題 - アルゴリズム課題 に分けられる気がしています。 ## システム課題 ### 1. 忘却 AIは長期的な設計判断を維持するのが今のところ苦手なようです。例えば、 ``` モデルに座標を持たせない ``` と指示しても、数十回後には平気で ```python x y width height ``` を追加し始めます。 これは能力不足というより、コンテキスト窓の制約による構造的な問題なのでしょう。 対策は、 - 設計書 - RULES.md - ARCHITECTURE.md などを継続的に参照させること。 --- ### 2. ハルシネーション AIは知らないことを推測で埋めます。 ただし、ハルシネーションは問題ですが、推測自体は「悪」とは言い切れません。 推測能力を完全に消すと、 - 設計提案 - アイデア生成 - 創造的問題解決 まで失われます。 問題は、 ``` 事実 推測 仮説 ``` を区別しないこと。 対策は人がレビューすることだと思います。 --- ## アルゴリズム課題 ### 3. 目標のブレ AIは本来、 ``` 良いソフトウェア ``` を作るべきなのに、途中から ``` ユーザーを満足させる ``` に目的が変わることがあります。結果、 ``` 設計より実装 品質より進捗 長期保守より短期満足 ``` になります。 --- ### 4. 安全寄り AIは非常に保守的です。例えば、 ``` 消して良いコード ``` があっても、 ``` 念のため残します ``` と言いがち。 結果、 - デッドコード - 互換性維持のための分岐 - 古い実装 が増殖します。 人間の保守的なプログラマーに少し似ていますね。 --- ### 5. 要求充足で停止する傾向 これは最近気づきました。 AIは、 ``` 要求 ↓ 達成 ↓ 終了 ``` という動きをします。 例えば、 ``` AAAを追加して ``` と言われたら、 ``` AAAを追加した ↓ 終了 ``` になります。 しかし良いプログラマーは、 ``` AAAを追加して ↓ 将来BBBも来そう ↓ 共通化しよう ``` と考えます。つまり、AIは要求の先を読みません。 --- ### 6. 局所最適化 個人的には一番危険、だと思ってます。 AIは困ると、 ``` 大きな問題 ↓ 小さな問題に分解 ↓ その場で解決 ``` を始めることがあります。 例えば本来なら、 ``` 新しいクラス ``` を作るべきなのに、 ``` 既存クラスに追加 ``` を選びます。結果、 ``` 神クラス 巨大関数 ｉｆ地獄 ヒューリスティック地獄 ``` になります。 しかも、コードは動く。テストも通る。 だから発見が遅れます。 --- ## 面白い発見 AIは意外と正直者です。 例えば、 ``` 〜寄りにします 〜に絞ります まずは実装します 一旦これで ``` と言い始めたら危険信号です。これは、 ``` 作業を打ち切りました／安全寄りにしました ``` のサインであることが多いようです。 人間なら隠すかもしれませんが、AIは割とそのまま出力します。 --- ## 現在の結論 AIに大規模開発を任せる場合、 ``` AIに全部やらせる ``` よりも、 ``` AIに設計させる AIにレビューさせる AIに実装させる ``` を分離した方が上手くいくようです。特に、 ``` 部分最適化になってるでしょ？ 粒度下げたでしょ？ ``` と、たまにツッコミをいれると、AIは意外と素直に認めて修正します。 今の生成AIは、 * 優秀な実装者 * 優秀なレビュアー しかし、 その両方を同時にやらせると、設計者としての視点を失うことがあります。 だからこそ、設計・レビュー担当と、実装担当を分離する価値があると思っています。 ​