大規模言語モデル（LLM）の活用が個人から組織へと拡大する中、プロンプトを従来のソースコードと同等の厳密さで管理する必要性が高まっている。
この記事では、プロンプトのコード化、Golden Datasetによる定量的評価、セキュリティガバナンス体制という3つの組織的実践と、エンジニアの役割変容について論じる。
AIを「個人の便利ツール」から「組織の信頼できる資産」へと転換すること考えについて整理する。
Prompt as Code：組織的実践の3つの柱
1. プロンプトのコード化と中央管理
プロンプトは「AIへの命令セット」であり、システムの挙動を決定する重要な資産である。これをExcelやドキュメントツールではなく、ソースコードと同様にGitで管理する必要がある。
実装パターン:
このようにYAMLやJSON形式でプロンプトを定義し、変数を外部から注入可能にすることで、以下のメリットが得られる：
- 再利用性: 同一プロンプトの複数箇所での利用
- テスト可能性: 変数を変更した自動テストの実施
- 変更履歴: Gitによる変更追跡
- レビュー: プルリクエストによる品質管理
2. Golden Datasetによる定量的評価
「AIの出力が改善された/劣化した」を感覚的判断ではなく、データに基づいて判定する仕組みが必要である。
Golden Datasetの定義: 本番環境で実際に発生した問い合わせ、典型的なユースケース、エッジケース（境界条件）を含むテストデータセットである。
| 入力例 | 期待される出力 | 評価基準 |
|---|---|---|
| 「返品したいのですが」 | 返品ポリシーの説明＋手順 | 正確性、トーン |
| 「配送はいつですか？」 | 配送状況の確認方法 | 簡潔さ |
| 「クレームです！」 | 謝罪＋エスカレーション | 適切な対応 |
プロンプト変更時には、必ずGolden Datasetでテストを実行し、性能の回帰（regression）がないことを確認する。これをCI/CD（継続的インテグレーション/継続的デリバリー）パイプラインに組み込むことで、品質の後退を防止する。
LLM-as-a-Judge（AIによる評価）: 人間が数百件の出力を手動でチェックすることは現実的ではない。そこで、より高性能なLLMを評価者として利用する手法が主流となっている。
評価用プロンプトの例：
3. セキュリティとガバナンス体制の確立
AIシステム特有のセキュリティリスクに対処する組織的体制が必要である。
主要なリスク:
| リスク | 説明 | 対策 |
|---|---|---|
| プロンプトインジェクション | 悪意のある入力によるAI指示の上書き | 入力検証、コンテキスト分離 |
| 個人情報の漏洩 | 入力・出力に含まれるPIIの不適切な処理 | PII自動検知とマスキング |
| 不適切な出力 | 差別的・有害なコンテンツの生成 | ガードレールモデルの導入 |
組織的対策:
- AIガバナンス委員会の設置: IT、法務、リスク管理、事業部門が参加するクロスファンクショナルな承認プロセス
- 責任者の明確化: 各AIユースケースに対する「AIシステムオーナー」の任命
- 監査ログの保持: すべてのAI通信の記録と追跡可能性の確保
知識の形式知化：AGENTS.mdとSKILL.md
組織の標準プロセスを文書化し、AIエージェントに学習させる仕組みである。
- AGENTS.md: プロジェクトの「憲法」。エージェントの役割、使用可能なツール、判断基準を定義
- SKILL.md: 具体的なワークフロー。「PRレビューの手順」「障害対応フロー」などを記述
これにより属人化を防止し、新メンバーのオンボーディングも効率化される。
エンジニアの役割変容：3つのパラダイムシフト
コードを書く人 → 環境を設計する人
従来のエンジニアリングは「正確な命令（コード）を書くこと」であった。AI時代のエンジニアリングは「AIが効果的に機能する環境を設計すること」である。
プロンプト、データ、ツール、メモリ、評価基準—これらすべてが「環境」の構成要素である：
- プロンプト: AIへの指示を明確化
- データ（RAG）: AIが参照すべき情報源の整備
- ツール（MCP）: AIが使用可能な外部機能の定義
- メモリ: AIが保持すべき情報の設計（短期/作業/長期記憶）
- 評価基準: AI出力品質の測定基準（Golden Dataset）
エンジニアの役割は、これらの要素を適切に組み合わせ、AIが安定的に価値を創出できる「環境」を構築することである。コーディング技術は依然として重要だが、それは全体のサブセットに過ぎない。
個人の技術力 → 組織のプロセス設計力
優れたプロンプトを記述できる個人の能力も重要だが、より本質的なのは「チーム全体が一定水準の品質を維持できる仕組み」を構築する力である。
従来のソフトウェア開発では、コードレビュー、テスト、CI/CDといったプロセスを通じて属人化を防止し、品質を担保してきた。AI開発においても同様のアプローチが必要である：
- プロンプトのGit管理と変更履歴の追跡可能性確保
- Golden Datasetによる回帰テストの自動化
- AGENTS.mdやSKILL.mdによる組織知の形式知化
- セキュリティチェック（PII検知、インジェクション対策）の標準化
完璧を目指す → 継続的改善を回す
従来のコードは決定論的である。同一の入力には必ず同一の出力が返される。しかしAIは確率的であり、完璧な初期設定は存在しない。
重要なのは、モニタリング、評価、改善のサイクルを高速で回す能力である：
- モニタリング: AI出力品質のリアルタイム監視（ドリフト検知）
- 評価: Golden Datasetによる定期的な性能測定
- 改善: 問題検出時のプロンプト調整と再テスト
この「Build-Measure-Learn」ループを週次または日次で実行できる組織が競争優位を獲得する。
また、AIシステムはエンジニアのみでは完結しない。法務、コンプライアンス、ドメイン専門家、プロダクトマネージャーとの協働が不可欠である。技術的正確性のみならず、組織的合意形成や、非エンジニアでもアクセス可能なツール選定（PromptLayerのようなノーコード編集環境など）も、エンジニアの重要な責務となる。
プラットフォームエンジニアリングの視点
プロンプトのコード管理やGolden Datasetによる評価といった実践は、プラットフォームエンジニアリングの考え方と高い親和性を持つ。
各自が車輪を再発明するのではなく、検証済みのプロンプトテンプレートを「Golden Path（推奨パス）」として中央で提供し、エンジニアが必要な時にセルフサービスで利用できる仕組みを構築する。これにより、個別の試行錯誤に費やす時間を削減し、組織全体の開発者体験（DX）を向上させることが可能となる。
結論：エンジニアリングパラダイムの転換
AI時代のエンジニアリングは、「コードを書く人」から「AIが効果的に機能する環境を設計する人」へと変容している。
3つの重要な転換:
- プロンプトは新しいコード: 厳密な管理とテストが必須
- 評価は感覚ではなくデータで: Golden DatasetとLLM-as-a-Judge
- 個人技から組織の仕組みへ: AGENTS.md/SKILL.mdによる形式知化
エンジニアの進化経路:
- AIを使う人 → AIを育てる人 → AIと協働する設計者
組織として適切な体制を整備し、エンジニア個人が必要な能力を習得することで、LLMを単なる実験的ツールから、ビジネス価値を継続的に創出する資産へと転換することが可能となる。