これまでに「プロンプトを言い換えるだけ」で、本番のLLMシステムをデバッグしたことがあるなら、この投稿はあなたのためです。
問題はモデルではありません。問題は指示です。
ほとんどのLLMの指示は、人が自分へのメモを書くような形で書かれています。非公式で、共有される文脈が前提として置かれており、それを誰かが保守している、というスタイルです。これは単発の実験ならうまくいきます。しかし、指示が一度だけ作成され、何千回も実行され、そして元の意思決定が行われた場にいなかったチームによって保守されるようなシステムでは失敗します。
失敗のモードは予測可能です：
文脈の崩壊により、永続的な事実、セッション上の判断、タスクごとの指示がひとつの塊に混ざります。何もキャッシュできず、すべてを再送しますし、1つを変えると別の何かが壊れます。
暗黙の制約「APIレイヤーに触るな」は、指示そのものではなく、誰かの頭の中やSlackスレッドにあります。
出力契約の指示は、何をすべきかを説明するのであって、正解がどう見えるかを記述しません。評価は主観になります。
出力が間違っているときにデバッグとしてリトライし、言い換えます。あなたは別の出力を生成するだけで、正しいものにはなりません。
ICS: Instruction Contract Specification
ICSは、REST API、データベーススキーマ、ネットワークプロトコルで既に使われているのと同じ規律を、指示レイヤーに適用します。寿命の異なる5つのレイヤーと、厳格なルールを定義します：
IMMUTABLE_CONTEXT
[長寿命のドメイン事実。キャッシュされる。決して言い直されない。]
CAPABILITY_DECLARATION
ALLOW src/ 内でのコード生成
DENY src/api/ 内の変更
REQUIRE 新規関数すべてに型アノテーション
SESSION_STATE
[このセッションに限った一時的な判断。CLEARセンチネルでクリアされる。]
TASK_PAYLOAD
[この呼び出しにおける特定のタスク。]
OUTPUT_CONTRACT
FORMAT: markdown
SCHEMA: { summary: string, changes: Change[] }
ON_VIOLATION: フィールドパス付きでエラーを返す
分離が儀式なのではありません。そこにこそトークン削減の源泉があります。
数学
素朴なアプローチ: cost(N) = total_tokens × N
ICSアプローチ: cost(N) = permanent_tokens × 1 + session_tokens × S + invocation_tokens × N
permanent_tokens > 0 かつ permanent_tokens < total_tokens なので、ICSはすべての N > 1 で安くなります。常にです。これはベンチマークではなく、数学的な恒等式です。
経験的には、N=10回の呼び出しで約55%のトークン削減。N=50では約63%。
ツールチェーン
このプロジェクトでは、完全なオープンソースのツールチェーンを提供します：
`pip install .
ics-validate my_instruction.ics # 構造的なコンプライアンス
ics-lint my_instruction.ics # 9つのセマンティックなアンチパターンルール
ics-scaffold --template api-review # スケルトンを生成
ics-diff v1.ics v2.ics # レイヤーを考慮した差分
ics-report prompts/*.ics # CIの集計レポート`
また、JVM向けのランタイムも含まれています。
状況
ICS v0.1は、最初の一般公開ドラフトです。仕様、ツールチェーン、そして20のベンチマークシナリオはオープンソースです（CC BY 4.0 + MIT）。セマンティクスが固定される前にフィードバックを歓迎します。
