お知らせ: 私は公式にX（Twitter）で活動を開始しました。新しいDevOpsのアイデアについては、X（Twitter）でも私に参加してください。 ここをクリック
記事要約:
ソフトウェア工学の歴史の大半において、アーキテクチャは構造に焦点を当てていた。
エンジニアは以下を設計した：
- サービス境界
- API
- データモデル
- インフラストラクチャ層
- 通信プロトコル
アーキテクチャは一つの主要な問いに答えた：
コンポーネントはどのように相互作用して、望ましいシステム挙動を生み出すべきか。
AI時代には、その問いは進化している。
システムが知能モデルに依存する場合、挙動はもはやコード構造だけで決定されるわけではない。
それはコンテキストによって決定される。
そしてこれが、新しい分野として登場している、コンテキスト・エンジニアリングだ。
従来のアーキテクチャ・モデル
従来のソフトウェア・システムでは、挙動は決定論的だ。
開発者が以下を定義すると：
- 入力
- ロジック
- 出力
システムは予測可能に挙動する。
従来、アーキテクチャはコードとサービスを効率的に整理することに焦点を合わせていた。
主な設計上の懸念には以下が含まれていた：
- スケーラビリティ
- モジュール性
- 保守性
- 耐障害性
アーキテクチャが定義されると、システムの挙動は内部に書かれたロジックから生じる。
AIはコンテキストに依存する挙動を導入する
AIシステムは異なる動作をする。
事前定義されたロジックを実行する代わりに、情報を解釈し、動的に応答を生成する。
出力は次の点に大きく依存する：
- プロンプトまたは指示
- 取得されたデータ
- 周囲のコンテキスト
- 適用された制約
- 対話の履歴
同一の2つのモデルでも、このコンテキストの構造次第でまったく異なる結果を生み出すことがある。
言い換えれば：
コンテキストがAI挙動のアーキテクチャになる。
コンテキスト・エンジニアリングが実際には何を意味するのか
コンテキスト・エンジニアリングは、AIシステムの挙動を形作る情報環境を設計する実践である。
次のような要素をコントロールすることを含む：
- プロンプトと指示
- 取得された文書または知識源
- ユーザー状態と会話履歴
- システムの制約とポリシー
- タスク固有のデータとツール
サービスとAPIだけに焦点を当てるのではなく、知能的な意思決定を導く情報入力を設計する。
なぜコンテキストはモデルよりも重要になることが多いのか
多くのチームは、AIの性能を向上させるにはモデルを切り替える必要があると最初に想定する。
実際には、最大の性能改善はしばしばより良いコンテキスト設計から来る。
例えば：
- 適切な文書の取得が精度を向上させる
- プロンプトの構造化が幻覚を減らす
- 制約の追加が信頼性を向上させる
- 例を提供することで一貫性が向上する。
モデルの知性は重要だ。
しかし、その知性をどれだけ効果的に適用できるかは、コンテキストの品質によって決まる。
アーキテクチャは情報フロー設計になる
従来のアーキテクチャの図は、システムがAPIを通じて通信する様子を示している。
AI主導のシステムでは、別の層が同様に重要になる：
生成される出力の前に、情報がモデルへどのように流れるか。
これには：
- 取得パイプライン
- コンテキストフィルタリング
- メモリ管理
- プロンプト構築
- 知識統合
これらのパイプラインを設計することが、中心的なエンジニアリングの課題となる。
システムは、適切な情報を適切な時にモデルへ提供しなければならない。
開発者はコンテキストのサイズと関連性を管理する必要がある
AIシステムは、限られたコンテキストウィンドウの中で動作する。
つまり、開発者は以下を決定しなければならない：
- 含める情報
- 除外する情報
- 関連データの優先順位の付け方
- 大規模データセットの要約方法
不適切なコンテキスト管理は、次のような問題を引き起こす可能性がある：
- 誤った回答
- 関連性のない情報
- コストの増加
- 性能の低下
したがって、コンテキスト・エンジニアリングは、慎重な情報選択と圧縮を必要とする。
評価はコンテキスト・エンジニアリングの一部になる
コンテキストが挙動を形作るため、エンジニアは継続的に評価する必要がある：
- コンテキストが出力品質を改善するか
- 特定のプロンプトがバイアスを導入するか
- 取得データが関連性を保つか
- システムがタスクを横断して一貫して振る舞うか
これは、時間とともにコンテキストを洗練させるフィードバックループを生む。
静的アーキテクチャとは異なり、コンテキスト・エンジニアリングは反復的なプロセスである。
コンテキスト・エンジニアリングは学際的思考を必要とする
従来のアーキテクチャは、計算機科学の原理に大きく依存している。
コンテキスト・エンジニアリングは追加の分野を加える：
- 情報検索
- 知識表現
- ヒューマン・コンピュータ・インタラクション
- 行動設計
- データキュレーション
エンジニアは、システムとコードだけでなく、情報が機械的推論をどう形作るかも考えなければならない。
開発者の新しい役割
AIシステムと共に作業する開発者は、ますます以下のように振る舞う：
- コンテキストデザイナー
- ワークフロー・アーキテクト
- 評価エンジニア
- システム挙動アナリスト
決定論的ロジックを書くのではなく、確率的システムを、慎重に構造化された情報環境を通じて導く。
彼らの仕事は、AIシステムが信頼性をもって挙動するための適切なコンテキストを確保すること。
従来のアーキテクチャは依然として重要である
コンテキスト・エンジニアリングはアーキテクチャを完全に置換するものではない。
インフラ設計、システムのスケーラビリティ、サービスの信頼性は依然として不可欠だ。
しかし、AI駆動のシステムでは、アーキテクチャだけで挙動を決定するには不十分だ。
システムアーキテクチャとコンテキスト設計の組み合わせが最終的な結果を定義する。
本当の要点
AI時代は、エンジニアリングの責任の新しい層を導入する。
従来のアーキテクチャはソフトウェア部品がどのように相互作用するかを決定する。
コンテキスト・エンジニアリングは、知的システムがどのように挙動するかを決定する。
開発者は、システムの構造だけでなく、機械的推論を導く情報環境も設計する必要がある。
AIがアプリケーション全体に組み込まれていくにつれて、このスキルは基本的なものとなるだろう。
知的システムでは、コードが構造を定義する。
しかし、コンテキストが挙動を定義する。
