グラフの成長段階で、木構造へ急いで固定してはいけない
プログラミング言語の文字列は、当初ほとんど設計するまでもないものに見える。文字の並びにすぎないのではないか。文字をメモリへ連続して格納し、長さ、連結、添字によるアクセスを提供すれば、それで話は終わるように思える。
C言語の文字列は通常、ゼロバイトで終わる char 配列である。strlen はゼロバイトより前にあるバイト数を計算し、s[i] はi番目の char を取り出す。ASCIIだけを扱うなら、一つの文字が一つのバイトに対応し、文字の順番、配列の添字、メモリ上の位置はほぼ同じものとみなせる。
JavaはUnicodeをより適切にサポートするため、String の公開セマンティクスをUTF-16コードユニットの上に築いた。length() はコードユニット数を返し、charAt() は16ビットの char を取り出す。一般的な文字であれば、依然として「一つの文字が一つの位置を占める」ように見える。しかし、基本多言語面の外にあるコードポイントは、サロゲートペアを必要とする。さらに、画面上で一つに見える文字が、複数のコードポイントから構成されることもある。
Rubyは、より多くの見方を残すことを選んだ。String はバイト列とそのエンコーディングを保持し、同時に bytesize、length、each_byte、each_char、each_codepoint、each_grapheme_cluster を提供する。同じ文字列をバイト、文字、コードポイント、書記素クラスタの単位で捉えられ、「文字」に自然な境界が一つしかないかのように装う必要がない。
Cは文字列をバイト列へ投影し、JavaはUTF-16コードユニット列へ投影する。Rubyは複数の投影を同時に公開する。どの設計にもそれぞれのトレードオフがあるが、いずれも同じことを示している。バイト、コードユニット、コードポイント、画面上の文字は、安定して入れ子になる何層かの容器ではない。エンコーディング、結合、言語上の規則によって結び付けられた、異なる種類の対象である。
高くつくのは、その選択が公開セマンティクスに組み込まれることだ。Javaは後から String の内部的な格納方法を変えられても、length() と charAt() の振る舞いは維持しなければならない。既存のプログラムが依存しているのは、これらのインターフェースが約束した関係だからだ。後になって、より完全な世界が見えたとしても、変更するのは難しい。
私たちはこうした問題を「早すぎる最適化」と呼ぶことが多い。しかし、最適化は表面的な問題にすぎない。その奥にあるのは、早すぎる固定化だ。対象と関係がまだ成長しているうちに、設計者が一つの関係を選び、それを唯一の組織原理へ格上げしてしまう。
AI Engineerに必要な能力とは
いまAI Engineerについて論じるときも、同じ道をたどりやすい。
私たちはまず、能力を一本の木として描くことに慣れている。ルートノードをAI Engineeringとし、その下をモデル、アプリケーション、インフラストラクチャに分け、さらにPrompt、Context、RAG、Agent、Workflow、Memory、Tool、Sandbox、Eval、Securityへと細分化する。それぞれの能力に場所が与えられると、学習ロードマップも姿を現す。何を先に学び、次に何を学び、どの階層まで到達すれば一人前なのかが示される。
この木はとても明快だ。問題は、AI Engineeringそのものがまだ安定していないことにある。
Evalはモデル能力に属するのか、それともソフトウェアテストなのか。Sandboxはインフラストラクチャなのか、それともAgentの実行能力とセキュリティ境界なのか。Context EngineeringはPromptの延長なのか、データエンジニアリングの一部なのか、それともプロダクトへの理解をシステムへ取り込む方法なのか。WorkflowとAgentは上下関係にあるのか、それとも組み合わせられる二つの実行メカニズムなのか。
これらの問いに唯一の答えを出すのが難しいのは、そもそも複数の関係が存在するからだ。
モデル能力はシステムに何ができるかを決め、Contextはモデルが何を見られるかを決める。ToolとRuntimeは現実の環境で何を実行できるかを決め、Sandboxと権限は何を変更できるかを制限する。Evalは最終的な結果が信頼に値するかを確認する。これらは一回のデリバリーに共同で作用しており、互いに独立した枝へきれいに分けることはできない。
AI Engineerに必要な能力は、すでに成長を終えた一本の木ではない。むしろ、いまも広がり続ける一枚のグラフに近い。
早すぎる木構造化が、偽りの学習ロードマップを生む
能力を木で表すことで最も生じやすい誤解は、統一された学習順序が存在すると思わせることだ。
モデルの訓練から始める人もいれば、APIやプロダクト開発から入る人もいる。データ、権限、デプロイを先に扱う人もいれば、実際のビジネスで最初に評価の問題に直面する人もいる。仕事によって制約は異なり、補うべき能力も異なる。
Coding Agentを開発するエンジニアには、コードベース、ツール呼び出し、Sandbox、タスクの状態、ソフトウェア検証に対する深い理解が必要になる。企業向けAIアプリケーションを作る人は、ビジネスプロセス、データ権限、Identity、統合、評価を先に扱う可能性が高い。モデルサービスを担当する人は、推論、コスト、レイテンシー、可観測性に目を向ける必要がある。
全員をAI Engineerと呼ぶことはできるが、同じ能力の木を共有する必要はない。
標準的な経路を早々に定めると、現時点で最も説明しやすい能力が幹に置かれ、領域横断的な能力は脇枝へ追いやられる。学ぶ人は目次に沿って知識を集め始めるが、それらの知識がどのように連携して一回のデリバリーを成し遂げるのかはわからない。チームも分類に沿って責任を分けた結果、能力と能力のつながりを誰も扱わない事態になりかねない。
木は、それぞれの能力にこう答えるよう求める。
私はどの分類に属するのか。
しかし、この領域がまだ成長している間は、こちらの問いのほうが重要だ。
どの能力とともに、どのような問題を解決するのか。
まず能力のグラフを残し、そこから学習の木を生成する
だからといって、能力を木で表すことに価値がないわけではない。
木は認知的な負荷を下げられ、具体的な目標に向けた経路を組むのにも適している。AIアプリケーションを開発したいなら、プロダクトの目標を起点に、Context、Tool、Workflow、Evalを中心とする学習の木を生成できる。Agent Runtimeを構築したいなら、実行環境、状態、権限、Security、可観測性を中心とする別の木を生成できる。
どの木も利用できる。ただし、それらは同じ能力のグラフから生成された異なるビューにすぎない。
より妥当なのは、まず能力の間で実際に生じている関係を記録することだ。モデルがツールの選択にどう影響するのか。Contextが権限によってどう制約されるのか。Runtimeが状態をどう保存するのか。Evalがモデルの出力と最終的なビジネス成果をどうカバーするのか。目標が明確になってから、現時点で必要な関係を選び、実行可能な学習経路へ投影すればよい。
グラフも無限に成長させてよいわけではない。多くのプロジェクトで検証された関係が、安定して繰り返し現れるようになったなら、カリキュラム、インターフェース、フレームワーク、役割定義として固定すべきだ。木が担う約束は、領域の成熟度に見合うものでなければならない。
探索段階では関係を残し、学習と実行の際にはビューを生成し、関係が安定してから構造を固定する。
文字列が残した教訓はこうだ。本当に高くつくのは、最初に多少の複雑さを残すことではない。まだ十分に理解されていない関係が、誰もが従わなければならないインターフェースへ早々に書き込まれてしまうことだ。
次にAI Engineerの学習経路を作るときは、まず目標を明記し、能力グラフから今必要な関係を選べばよい。そこから生成した木は今回の目標にだけ使い、領域全体の最終構造を装わせない。