AIの使い方は、静かにしかし決定的に変わり始めている。
これまで主流だったのは「プロンプトファースト」という発想だった。
いかに上手に説明するか。いかに漏れなく条件を書くか。いかに長く丁寧に指示するか。AIを動かす中心は常に入力文だった。
しかし、Codexのような環境常駐型エージェントを使い始めると、ある違和感に気づく。
長い説明を書かなくても動く。
むしろ説明を減らしたほうが精度が上がることすらある。
なぜか。
答えは単純で、AIが読む対象が「会話」から「環境」へ移ったからだ。
プロンプトファーストの時代
従来のチャットAIはフロー型だった。
一回の会話が単位であり、履歴はあくまで延長線にすぎない。だから毎回、背景、前提、目的、制約を説明する必要があった。
優秀なプロンプトエンジニアとは、情報を圧縮し、論点を整理し、誤解の余地を減らせる人間だった。AIの性能よりも、入力者の構造化能力が差を生んでいた。
しかしこのモデルには限界がある。
会話が長くなるほど遅くなり、焦点がぼやけ、重要な前提が埋もれる。人間が毎回メモを持ち歩かなければならない会議に近い。
ソースファーストの台頭
Codex型のAIは違う。
彼らはまずフォルダを見る。READMEを見る。ファイル構造を見る。過去成果物を見る。
つまり環境を読む。
プロンプトは補助信号に近い。
この転換は大きい。AIに説明するのではなく、AIが読める世界を用意するという発想になる。
例えば執筆作業。
以前は章の意図や方向性を毎回説明していた。今はchapter4というフォルダがあり、そこに原稿、参考資料、decision_log、philosophyが置かれている。
AIはそれらを横断し、状況を再構築する。
やってほしいのは改善だけでよい。
長文の指示は不要になる。
なぜソースが強いのか
理由は三つある。
第一に、ソースは継続性を持つ。会話はその場の発話だが、ファイルは履歴と一貫性を含む。統計的に安定している。
第二に、実例は抽象命令より強い。簡潔に書けと百回言うより、理想的な原稿を一つ置いた方が効く。LLMは具体例を強く参照する。
第三に、意味検索が前提になっている。単語一致ではなく概念近傍で探索する。判断基準という語がなくても、評価軸やポリシーといった表現から関連箇所を拾う。
自然言語で整理されたソースは極めて強力になる。
プロンプトは設計書ではなくトリガーになる
ソースファーストに移行すると、プロンプトの役割は変わる。
設計書ではなく起動スイッチになる。
第4章を改善して。
この銘柄のリスクを再評価して。
思想の一貫性を確認して。
これだけで動く。
判断材料はすでに環境の中に存在しているからだ。
良いソースとは何か
ただファイルを置けばよいわけではない。
検索される前提で書く必要がある。
見出しがある。
概念名が明示されている。
判断理由が言語化されている。
この三つが揃うと意味探索の精度は大きく上がる。
逆に、temp_final2や新しいやつといった命名が増えると探索空間が崩れる。構造が悪いとソースファーストは逆効果になる。
思考様式の変化
最も興味深いのはここだ。
ソースファーストで作業を続けると、人間の思考自体が変わる。
発話で考えるのではなく、構造で考えるようになる。
思いつきを投げるのではなく、将来参照されることを前提に書く。意思決定をログ化する。判断基準を明示する。
つまり、自分の思考を検索可能にする。
これは単なるAI活用法の変化ではない。思考の保存形式が変わるということだ。
フローからストックへ
プロンプトファーストはフローの発想だった。瞬間的な知的労働。
ソースファーストはストックの発想だ。環境に知性を埋め込む。
AIを賢くするために長いプロンプトを書く時代は終わりつつある。代わりに、賢く読める環境を設計する時代が始まっている。
この変化を理解すると、仕事の重心が移動する。
入力の巧拙から、構造の設計へ。
そして最終的には、自分の思想そのものをソースとして管理する段階に入る。
結び
プロンプトファーストからソースファーストへ。
それは単なるテクニックの違いではない。
知的生産が変わるという話である。
