コードを直す前に、文脈を整えよ: 局所最適化とコンテキスト設計の新しい作法

Jun 04, 2026

1 min read

3 views

62%

まず問いをひっくり返す

多くの人は、コードを速く書くことをAI活用の中心だと思っている。だが本当に差がつくのは、書く前ではなく、書いた後に何をするかだ。実装が終わった瞬間、私たちはたいてい気が緩む。ところがその直後こそ、コードベースは最も壊れやすく、最も整えやすい。ここに、AI時代の開発で見落とされがちな逆説がある。

重要なのは、AIに「全部やらせる」ことではない。どの粒度の問題を、どの文脈の大きさで扱うかを見極めることだ。局所的なクリーンアップには局所的な文脈を、コードベース横断の変更にはより広い文脈を与える。この使い分けができると、AIは単なる自動化ツールではなく、設計の補助輪になる。

そして、この話は単なる操作テクニックでは終わらない。実は、リポジトリを立ち上げる瞬間から、どれだけの文脈を持たせるかという設計が始まっている。つまり、AI開発の本質は「コードを書くこと」ではなく、文脈を編集することにある。

速い修正ほど、狭い文脈が効く

実装後の局所的なクリーンアップがやりやすいのは、問題の輪郭がはっきりしているからだ。たとえば、関数名を少しわかりやすくする、重複した条件分岐を整理する、例外処理を一箇所だけ整える。こうした作業は、広大な情報を見せるより、今触っている箇所に注意を集中させたほうがうまくいく。

これは料理に似ている。スープ全体を作り直すときに、鍋の中身を一口分だけ見ていても足りない。しかし、最後に塩加減を整えるだけなら、鍋全体を見渡す必要はない。むしろ見すぎると、余計な判断が増えて味がぶれる。コードも同じで、局所最適の仕事には局所的な視野が適している。

ここで大切なのは、AIを「万能な大きな脳」として使わないことだ。小さな修正ほど、判断軸は明快であるべきだし、余計な履歴や周辺事情はノイズになりうる。だからこそ、細部を整える場面では、狭く切った文脈が強い。これは単に入力を短くする話ではなく、認知の焦点を絞る設計の話だ。

局所修正の品質は、情報量ではなく、焦点の鋭さで決まる。

この視点で見ると、後処理のクリーンアップは面倒な付録ではない。むしろ、開発フローの中で最も知的な部分のひとつだ。なぜなら、そこでは「何を変えるか」だけでなく、「何を変えないか」も同時に決めるからだ。

大きな変更ほど、文脈の編集が本体になる

一方で、フレームワーク移行やコードベース横断の変更は、まったく違う種類の仕事だ。ここでは局所的な美しさより、整合性が問われる。単一ファイルだけを見ていると正しく見える変更が、別の層では破綻する。設定、依存関係、命名規則、テスト、例外の流れ、非同期処理の前提。こうしたものは互いに絡み合っている。

このとき必要なのは、より広い地図だ。山道の修理と都市計画は違う。目の前の穴を埋めるだけなら局所で足りるが、道路網を変えるなら、全体の交通流や接続点を見なければならない。コードベース横断の変更でAIを使う意味は、単に大量の置換を速くすることではない。変更の波及を見える化し、整合性の崩れを先回りして防ぐことにある。

ここで初めて、コンテキストウィンドウは単なる制約ではなく、設計の道具になる。広く見せればいいわけではない。広く見せるときほど、何を含め、何を捨てるかが重要になる。関係のない履歴を入れすぎると、AIはそれらに引っ張られる。逆に必要な前提が欠ければ、表面上は正しくても実運用で壊れる。

大きな変更の難しさは、コード量ではなく、関係性の数にある。

だから、広い文脈が必要な場面では、AIに全体を丸投げするのではなく、意味のある断面を作る必要がある。たとえば、変更対象の主要な境界、依存の起点と終点、テストがカバーする振る舞い、移行前後の互換性条件。これらを明示して初めて、広い文脈は力を持つ。文脈とは、単に情報を詰め込んだ箱ではなく、判断を導くために編まれた構造なのだ。

本当に大事なのは「コードをどう書くか」ではなく「作業の粒度をどう切るか」

この2つの考え方をつなぐと、ひとつの重要な原則が見えてくる。開発の質は、AIに渡す命令の巧拙だけでなく、作業をどの粒度に分割するかで決まるということだ。

粒度が粗すぎると、何でも一度に処理しようとして破綻する。粒度が細かすぎると、全体整合性を見失って局所的な修正の寄せ集めになる。優れた開発者は、タスクを単に分割するのではなく、文脈のサイズとタスクの性質を対応づける。

この対応づけは、次のように考えるとわかりやすい。

局所修正: 1つの関数、1つのファイル、1つのバグ。狭い文脈で深く見る。
横断変更: 複数モジュール、複数設定、複数テスト。広い文脈で関係を見る。
移行作業: 旧仕様から新仕様へ橋をかける。途中状態をどう安全に保つかを見る。

この3つは似ているようで、必要な視野がまったく違う。なのに現場では、すべてを同じ感覚で扱ってしまいがちだ。すると、簡単な修正に過剰な情報を与え、難しい変更に情報を与えなさすぎる。AIの性能差より、問いの切り方の差が結果を左右するのである。

この意味で、文脈ウィンドウの理解は、メモリの話というより、設計の話だ。どれだけ詰め込めるかではなく、どこで切るか。何を見せるかではなく、何を隠すか。AI時代の熟練とは、力任せに全体を押し込むことではなく、必要な判断だけが浮かび上がる場を作ることにある。

リポジトリを作る瞬間に、すでに勝負は始まっている

もうひとつ見逃せないのは、文脈の問題が作業中だけではなく、作業開始時点から始まっていることだ。新しいリポジトリを立ち上げるとき、最初にどんな構成にするか。どんな命名にするか。どんなテストの骨格を置くか。どんなREADMEや設定を用意するか。これらは全部、後からAIが理解しやすい文脈を作っている。

たとえば、空っぽの箱に後から説明を足すより、最初から意図が見える箱を作ったほうが、AIは迷いにくい。これは人間のチームでも同じだ。初期の設計が雑だと、後から何度も文脈を説明し直す羽目になる。逆に、構造が良ければ、追加変更は局所的で済む。

つまり、良いリポジトリは単なるコードの置き場ではない。将来の変更に対して、問いの形を先に整えておく装置だ。ここで重要なのは、AIは既にある文脈を読むだけでなく、文脈の質に強く影響されるという点だ。雑な土台は雑な出力を呼ぶ。整理された土台は、整理された提案を呼ぶ。

この考え方は、開発の時間軸を変える。多くの人は、実装後に整理すると思っている。だが実際には、整理は最初から始まっている。だからこそ、リポジトリ作成時の一手が、その後のクリーンアップの難易度を決める。

Key Takeaways

局所修正には狭い文脈を使う。 余計な情報はノイズになりやすく、焦点がぼやける。
横断変更には広い文脈を使う。 依存関係、互換性、テストのつながりを見ないと破綻しやすい。
タスクの粒度と文脈のサイズを対応させる。 すべてを同じ深さで扱わない。
リポジトリ設計は前処理ではなく、文脈設計そのもの。 最初の構造が後のAI活用の質を決める。
AIに任せる前に、何を見せるかを決める。 その編集こそが、最も重要なスキルになる。

結局、AIはコードを書く道具ではない

AIを使うと、つい「どこまで自動化できるか」に意識が向く。しかし本当に価値があるのは、自動化の範囲を広げることではなく、人間の判断が最も効く位置に作業を再配置することだ。局所的なクリーンアップでは、細部の判断を鋭くする。広い移行では、関係性を見渡す。リポジトリ作成では、その後の判断がしやすい土台を作る。

この三つをつなぐと、ひとつの結論にたどり着く。AI時代の開発は、コードを書く技術から、文脈を設計する技術へ移っている。そして、文脈を設計するとは、単に情報を増やすことではない。必要なときに必要な視野を持たせることだ。

だから次にAIでコードを触るときは、こう自問してみるといい。これは局所の仕事か、それとも横断の仕事か。必要なのは短い焦点か、広い地図か。もしこの問いに答えられるなら、あなたはもう単にコードを直しているのではない。変更が壊れない条件そのものを設計しているのである。