1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIを迷子にさせないために。

1
Posted at

1. 「ちょっとした修正」のたびに、コンテキストが雪だるま式に膨らむ背景

AI駆動開発(AI-Driven Development)を継続的に実践していると、かなり高い確率で同じ問題に突き当たる。

最初のうちは、驚くほど快適だ。単一のファイルや関数、局所的な責務の範囲であれば、AIに数百行のコードを渡すだけで十分に精度の高い修正が得られる。しかし、開発が進みコードベースが成長するにつれて、徐々に状況が変わっていく。

「このロジックだけをピンポイントで直したい」

そうして少しの修正を行うだけなのに、関連する型定義や呼び出し元の処理、状態管理や副作用の流れ、さらには暗黙的に共有されたデータ構造や、実質的なSoT(Source of Truth)になってしまっている別モジュールのコードまで。

周辺のコンテキストを雪だるま式にプロンプトに添付しなければ、AIが安全に修正できなくなっていく。

これは単純なトークンコストや経済性の問題ではない。「AIにどこまで読ませれば安全なのか、人間側にも分からない」という、システムの構造的な問題であるように思える。優秀なモデルを使っているはずなのに、開発のテンポが徐々に重くなっていく。その原因は、AIの知能不足というよりも、コードベース側の構造に潜んでいるのではないだろうか。

2. 人間が設計に執着してきた理由と、AIが模倣する「レビューの再実行」

この構図は、実は昔から何も変わっていない。ソフトウェア開発において、人間のアーキテクトも長年まったく同じ問題に苦しんできた。

・UI層が業務ロジックの内部を直接汚染している。
・別モジュール間で意図しない参照共有が起きている。
・処理の変更が予期せぬ場所に影響を与える。

レガシーコードのリプレイスを経験したエンジニアであれば、誰もが一度は目にしたことのある光景だろう。本来これらは、カプセル化の破綻やアクセス境界違反、責務分離の崩壊として排除されるべき設計ミスだ。

しかし現実の開発においては、「今すぐ動くこと」が優先されがちであり、未来の健全性よりも今日のリリースの方が価値を持つことも少なくない。

そのため多くの言語やフレームワークは、長期的な堅牢性よりも即効性や柔軟性を優先し、後から何でも動的に触れる方向へと進化してきた側面がある。

言うなれば「人間の超人的な規律と努力によって、構造の破綻を力技で抑え込む」ことを前提とした設計。

それ故にAIは、その「人間の努力」を健気に模倣している節がある。AIが大量のコンテキストを必要とする本当の理由は、設計レビューという人間の知的労働を、プロンプトを投げるたびにその場で再実行しているからだとは思えないだろうか。

さて思い返してほしいが、設計レビューの際に一度も指摘をせずに済んだことは?

人間ですら見落として壊してしまう構造を、AIだけが壊さずに制御し続けられるという期待は、少し非現実的なのかもしれない。

3. 「見えていること」と「触れていいこと」の分離

最近、自分はこの問題に対する一つのアプローチとして、「構造の可視性」と「構造への依存権」を切り離すことはできないか、という方向性を模索している。

従来のオブジェクト指向や一般的な型システムでは、「オブジェクトを渡す」ことは、すなわち「その内部へ自由にアクセスする権限を丸ごと与える」ことと同義だった。つまり、「見えていること」と「触れていいこと」が未分化のまま結合している。

しかし、人間とAIの双方が迷子にならないために真に必要なのは、「存在は見えているが、触れていい範囲は静的に厳格に制限されている」という構造ではないかという仮説だ。

【模索している設計思想のイメージ】
・どのパスを Read 可能か
・どこの状態を Write 可能か
・どの関数を Call 可能か
これらを、値の形状を定義する「型」とは別の「静的契約(Capability)」としてコード側で定義する。

契約外のアクセスが発生した場合は、人間がレビューで指摘するのではなく、コンパイルや静的解析の段階で機械的に弾く。

もしこのような仕組みが成立するならば、AIに巨大な文脈を毎回読ませる必要性は大幅に減る可能性がある。関数が「何に依存してよいか」が静的に閉じているならば、AIは許可された範囲の境界線(エンベロープ)だけを見ればよくなるからだ。

これは当然、人間側にとっても大きなメリットをもたらす。コードレビューのたびに「そこは触らないでほしい」「そこに依存を作るのは危険だ」「その参照共有はバグを産む」と言い続け、消耗する必要がなくなる。

契約違反を、人間の規律ではなく、構造そのものの制約によって未然に防げるようになる。

さらに興味深いことに、その「関数ごとの契約(プロファイル)」を自動生成する行為自体は、むしろAIが非常に得意とする領域かもしれない、とも考えている。

4. AI時代の「綺麗な設計」の再定義に向けて

このアプローチはまだ完全に研究・実験の段階であり、解決すべき課題も多い。ただ、AI駆動開発が当たり前の前提になっていくこれからの時代において、いわゆる「クリーンアーキテクチャ」の評価軸は少しずつ変化していく予感がしている。

それは、「AIに大量のコンテキストを読ませなくても、安全に変更を完結できるコードであるか」という新たな指標だ。

これは決して、AIに過剰に最適化された歪なコードを目指すという意味ではない。AIに余計な周辺コードを読ませなくていい構造というのは、巡り巡って、人間のエンジニアにとっても認知負荷が極めて低い構造に他ならないからだ。

依存の境界が明確に閉じ、影響範囲が局所化され、行為の権限が静的に制御されていること。それは、私たちが昔から理想として掲げてきた設計のゴールそのものでもある。

ただこれまでは、それを維持するためのコストをすべて人間の脳内リソース(規律)に頼らざるを得なかった。AI時代が到来し、「境界のないコードはAIがすぐに壊してしまう」という痛みを伴う現象を通じて、その古典的な重要性が形を変えて再び露呈し始めているのではないだろうか。

毎回、AIにすべてを理解させて力技で解かせるアプローチには、効率面でも構造維持の面でもいずれ限界が来る。

「ここだけを見れば、絶対に他を壊さずに直せる」

その静的な防壁を、コード自体が自律的に持てるかどうか。最近はその仮説を検証するための実装と実験を個人的に続けている。まだ粗削りな段階ではあるが、この設計思想やアプローチ自体に興味がある方向けに、検証用のリポジトリを公開している。

是非、忌憚のない意見を聞かせてほしいと思う。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?