AIに数千字のPromptを詰め込まない：PROSE Agent開発フレームワーク入門

深掘り：PROSEとは何か

PROSEは新しいプログラミング言語でも、インストールするソフトウェアでもありません。Agentic Software Developmentのための工学的な規律です。

正しいタイミングで、必要な情報だけを見せ、明確な一つの仕事だけを任せ、本当に必要な対象だけを操作させる。

以下では、利用者がログインしてイベントを閲覧・申込し、管理者が参加者一覧を確認する「学内イベント申込サイト」を例に考えます。

P：AIにプロジェクト全体を一度に読ませない

Progressive Disclosure：段階的開示

申込ボタンの位置を変えるだけなら、必要なのはReactコンポーネント規則、UI規則、現在のページコードです。DB Migration、JWT更新、デプロイ、ログ、API権限は不要です。正しい情報でも、無関係なら注意を薄めます。

AGENTS.mdを百科事典から地図へ

ルートファイルには、フロントエンドなら frontend.md、APIなら backend.md、DBなら database.md、認証なら auth.md を読む、とだけ案内できます。知識は必要になった時点でコンテキストへ入ります。

Skillもオンデマンド読み込み

Skillの description は能力索引です。DB変更時にフォーム検証Skillは不要ですが、申込フォーム作成時には入力検証、エラー表示、送信規則を読み込みます。大切なのは、すべてを教えることではなく、知識の場所と読むタイミングを教えることです。

R：一度に機能全体を作らせない

Reduced Scope：作業範囲を縮める

「イベント申込機能を実装する」は一つに見えて、データ設計、API、画面、認証、重複申込、テストを含む小さなプロジェクトです。判断基準は、Agentが終えたあと何が残るか。成果物を一文で説明できなければ、さらに分割します。

1. 申込データ構造を設計し、registration_schema を残す。
2. SchemaからAPIを作り、registration.ts を残す。
3. フォームを作り、RegistrationForm.tsx を残す。
4. APIへ接続し、フォームと api.ts を更新する。
5. 正常申込と重複拒否を検証し、registration.test.ts を残す。

Agent Debugの黄金手順

「成功表示なのにDBに記録がない」問題は Diagnose → Implement → Validate に分けます。最初は原因と証拠だけを調査し、次に関係するコードだけを修正し、最後に本物のテストを実行して書込と重複拒否を証明します。それぞれが「なぜ壊れたか」「どう直すか」「本当に直ったか」に集中できます。

O：「究極のPrompt」を作ろうとしない

Orchestrated Composition：編成による組み合わせ

スーパーPromptは、コード、DB、テスト、セキュリティ、UI、API、出力、Gitの規則を一つの塊にします。Agentが失敗しても、どの規則やコンテキスト層が原因か分かりません。

代わりに、プロジェクト規則 + フロントエンド規則 + DB規則 + Skill + Agent役割 + 今回の作業 という部品に分けます。AGENTS.mdは「いつ何を使うか」、Instructionsは「プロジェクトの規則」、Skillは「この種類の作業手順」、Docsは「プロジェクト自体」、Promptは「今回どう組み合わせるか」を担当します。

ルート AGENTS.md、領域別の instructions/、再利用可能な skills/、作業テンプレート prompts/、知識を置く docs/ という構造なら、Promptは全知識の倉庫ではなく、既存モジュールの指揮役になります。

S：AIが決して間違えないと信じない

Safety Boundaries：安全境界

問うべきは「AIが間違えるか」ではなく、「間違えた場合に最大で何を壊せるか」です。「慎重に操作してください」という一文は、ファイル、Terminal、DB、Secret、削除、デプロイの現実的な権限制御にはなりません。

Agentごとに異なる鍵を渡す

• Code Writer：src の読書き、検索、テストは可能だが、本番デプロイ、Secret、DB削除、CI/CD変更は不可。
• Reviewer：コードを読み、検索、Lint、テストはできるが、役割は問題発見であり、勝手に修正しない。
• Test Runner：テストは実行できるが、失敗テストを削除したり本番コードを変えたりして通過させない。

STOP：人間に残す判断

テーブル削除、認証、公開API、権限、本番デプロイの変更はSTOP Gateを発動します。Agentは理由、影響範囲、Migrationの必要性を説明し、人間の確認を待ちます。

「通るはず」は「通った」ではない

信頼できる工程は実際に npm test を実行し、「23 passed, 1 failed」のように現実を報告します。コマンド、テスト、API応答、ファイル結果はAgentを現実につなぐ錨です。正しいと思うだけでなく、正しいと証明します。

E：なぜ一つのプロジェクトに複数のAGENTS.mdが必要なのか

Explicit Hierarchy：明示的な階層

規則はコードの場所に沿って作用すべきです。ルートはTypeScript、テスト、Secret、Commitを定め、frontend/AGENTS.md はReact、PascalCase、Loadingを、backend/AGENTS.md はResponse、入力検証、Repositoryを、backend/auth/AGENTS.md はTokenをログに残さない、認証変更はSTOP、CookieはHttpOnlyという規則を追加します。

backend/auth/session.ts を変更するとGlobal + Backend + Authが適用されますが、frontend/Button.tsx にTokenやSessionの規則は不要です。国の法律、地域の規則、会社の制度のように、階層が規則の管轄を明確にします。

Prompt EngineeringからAgent Engineeringへ

1. P：Agentは何を見るべきか。
2. R：今回はどこまで行うべきか。
3. O：規則と能力をどう組み合わせるか。
4. S：最大で何をしてよいか。
5. E：どのコードにどの規則が適用されるか。

5原則は情報、作業、能力、権限、作用範囲を制御します。管理対象は一つのPromptではなく、Agentの作業環境全体になります。

実践ガイド：初心者はどこから始めるべきか

個人プロジェクトの初版に、十数個のAgentや数十個のSkillは必要ありません。ルート AGENTS.md と docs/、instructions/、src/ から始められます。

1. いつ何を読むか：フロント、バックエンド、DBの作業を対応する説明へ案内する。
2. いつ人間に聞くか：ファイル削除、Schema、認証、公開API、本番変更の前で止まる。
3. どう完了を証明するか：関連テストを実行し、実結果、変更ファイル、残課題を報告する。

この三つだけでも、「全権限を持ち、数千字のPromptを背負う万能Agent」より保守可能なシステムに近づきます。