AIエージェント用の意思決定スコアリングスキルを作成する

※本記事は2026年6月16日に米国で公開された Build a Decision-Scoring Skill for Any Agentの抄訳です。本記事の正式言語は英語であり、その内容および解釈については英語が優先されます。

プロジェクトには技術的な判断がつきものですが、その時点で文書化されることはほとんどありません。後になって誰かが「なぜこの実装を選んだのか」を知りたくても、その根拠はSlackのスレッドや会議中の記憶、あるいはすでにチームを離れているかもしれない人の頭の中にしか残っていないのです。

AIを使えば、プロジェクトに重要なコンテキストの喪失を防ぎ、アーキテクチャーの原則を厳密に適用できます。意思決定スコアリングスキルを実装することで、プロジェクトチームは、コーディングエージェントをエンジニアリング設計のガードレールとして活用できます。この記事では、幅広い要件の聞き取りから始めて検証可能な形で意思決定を記録する、構造化されたフレームワーク「/decideパイプライン」を構築する方法を紹介します。

技術的な意思決定を支援するスキル

Salesforce Ada Agent Skills（英語）は、コードの記述にとどまらない、さまざまなエージェントスキルを集めたオープンソースのレポジトリです。/decideは、AIを使って技術的な意思決定を進める、構造化されたパイプラインです。たとえば、「/decide managed package vs. unlocked package vs. unpackaged metadata for distributing utilities across 3 orgs」（3つのSalesforce組織に共通のユーティリティを配布する場合、管理パッケージ、ロック解除済みパッケージ、パッケージ化しないメタデータのどれを選べばよいか）と入力してみましょう。すると、コーディングエージェントが、ユーザーから情報を収集して、公式ドキュメントにもとづく選択肢を提示します。さらにユーザーが実際の運用をもとにリスクを評価できるように表を出力し、スコア付きの推奨プランを提案して、その推奨案を意思決定の記録としてディスクに書き込みます。

出力はファイルとして残るため、バージョン管理やレビューが可能で、経緯を知りたい人がいつでも参照できます。

要件の聞き取り、評価基準の検討、スコアリングという基本パターンは、システム管理者（Admin）、開発者（Developer）、アーキテクト（Architect）を問わず、あらゆる技術的な意思決定に応用できます。これが「ADA」の由来です。以下の例ではClaude Codeを使っていますが、このスキルはどのAIエージェントでも使えるように設計されており、GitHubにはGeminiやCodex CLI向けのひな形も用意されています。
Claude Codeのdecideスキル

パイプラインの流れ

パイプラインでは、ステップを進めながら意思決定の範囲とコンテキストを絞り込んでいきます。各ステップの出力によって、次のステップの入力の範囲が決まります。幅広い情報収集と調査から始まり、最終的に1つの検証可能な意思決定スコアを決定します。
意思決定パイプライン

ステップ	内容
1. 情報収集	データの量、スケジュール、チームのスキル、制約など、この意思決定に特有の情報を収集します。AIエージェントは体系的な質問をし、decideコマンドの後に記述した内容についてはスキップします。
2. 解決策の選択肢	公式ドキュメントを1回で幅広く調査し、結果を表にまとめて提示します。次に進む前に、人が内容を確認し、追加、削除、修正を行います。
確認とレビュー
3. 評価基準	調査結果を踏まえて、この意思決定において「より良いもの」を判断する基準が定義され、人が確認します。評価基準が抜けていると、その観点の背景や状況が最終的なスコアに十分に考慮されない可能性があります。
確認とレビュー
4. リスク評価	評価基準と照らし合わせて、各選択肢のリスクの根拠を、引用を添えて示し「低」「中」「高」のいずれかで評価します。このデータをもとに意思決定が行われます。スコアが算出される前に、人がこのリスク評価の妥当性を検証します。
確認とレビュー
5. 意思決定スコアの算出	Well-Architectedフレームワークの各評価軸について、リスクに重みを付けてその合計スコアを算出します。最も高いスコアの選択肢が推奨案になります。スコア以外の判断によって結果が覆されることはありません。
永続的なドキュメントの作成（任意）

主な設計パターン

前述のパイプラインは、このスキルが実行する処理を示したものです。以下に、このスキルの実装方法と、信頼性と適応性を備え、技術的な意思決定を安心して任せられるスキルにするための設計パターンを紹介します。これらのパターンを組み合わせることで、内容を検証して共有し、その後の作業にも活用できる出力が得られます。

フォルダー構造

このスキルは、複数のMarkdownファイルからなるディレクトリとして構成されています。

1salesforce-ada-agent-skills/
2 ├── CLAUDE.md # グローバルルール
3 ├── .mcp.json # MCPサーバーの構成
4 ├── .claude/
5 │ 　　└── skills/
6 │ 　　　　　├── learn/
7 │ 　　　　　│　　 └── SKILL.md # 学習ワークフロー
8 │　　　　　 └── decide/
9 │ 　　　　　　　　└── SKILL.md # パイプラインのステップと制約
10 ├── knowledge/
11 │ 　　├── formats/ # 共通の出力テンプレート
12 │　　 │ 　　├── options-format.md # ソリューションの選択肢一覧用テンプレート
13 │ 　　│　　 ├── criteria-format.md # 評価基準用テンプレート
14 │　　 │　　 ├── risk-matrix-format.md
15 │　 　│　 　└── decision-format-*.md # 意思決定記録の出力テンプレート
16 │　　 ├── scoring/ # 意思決定スコアの算出方法
17 │ 　　└── modifiers/ # 組み合わせ可能な観点
18 └── output/
19 　　　└── decisions/ # 生成された意思決定の記録

CLAUDE.md （レポジトリのルート）では、スコアリングに使う各評価軸の重み、MCPのソース選択ルール、さらに、意思決定スキル全体に適用される厳格な制約を定義しています。スキルファイル（SKILL.md）はパイプラインの処理順序を管理し、CLAUDE.mdは各ステップを規定するルールを管理します。

「/decide」と入力するとSKILL.mdが読み込まれ、パイプラインの順序を制御します。フォーマットファイルは、 AIエージェントが解釈することなく、コピーして使用するテンプレートです。そのため、会話の長さにかかわらず一貫した出力を生成できます。スコアの算出方法は、最後のステップでのみ読み込まれます。スコアの算出方法には、約350行にわたって詳細な評価基準が記されているため、早い段階で組み込むと、情報収集の段階でAIエージェントの注意を分散させてしまうことになります。

このようにファイルを分けておくと、パイプラインのロジックに手を加えずにフォーマットを改善したり、ステップを変更せずにスコアリングの評価軸を入れ替えたりすることが可能になり、各段階でAIが参照する情報量を必要最小限に抑えられます。

最終的には人が判断

各ステップの最後で、AIエージェントはいったん作業を停止し、次のステップに進んでよいかを確認します。どの確認ポイントでも分析内容を調整して、選択肢の追加や評価基準の削除、評価の見直しが可能です。この仕組みによって、最初のステップで生じた誤った前提が、途中で検証されないまま推奨案まで持ち越されることを防げます。これにより、開発者の実務経験を最大限に活かし、より質の高い出力を得ることができます。
意思決定に必要な詳細情報を聞き取る質問

早い段階で幅広く情報を収集し、その後で事実関係を検証

解決策の選択肢を探るステップで最初に行う調査では、広範なクエリーを使用し、個々のアプローチを都合よく選ぶのではなく、複数のアプローチを一度に提示します。それぞれの選択肢は、提示する前にドキュメントをもとに妥当性が検証されます。さらに、リスクマトリックスに記載される事実関係についても、評価を付ける前に的を絞った検索で確認します。このように複数の段階で検証することで、幅広くすべての選択肢を公平に洗い出しながら、掘り下げた調査で根拠のない記述が最終スコアに入り込むことを防ぎます。

このスキルは、ドキュメント検索に対応したMCP（Model Context Protocol）サーバーがなくても機能します。MCPサーバーを利用できない場合は、Web検索やAIエージェントの学習済み知識を代わりに使用し、どの方法で情報を裏付けているかを明確に示します。とはいえ、質の高い意思決定には質の高いドキュメントが欠かせません。そこで、管理者、開発者、アーキテクト向けの最新の公式ドキュメントを対象に、キーワード検索とベクトル検索を実行できるカスタムMCPサーバー、salesforce-content（英語）を構築しました。MCPで利用できるドキュメントであればどれでも機能します（このレポジトリには、設定不要で使える代替手段としてContext7の設定も含まれています）。ただし、Web検索ではソースが解析しにくい場合に重要な情報を取りこぼすことがよくあるため、信頼できるSalesforceの情報源が直接インデックス化されたsalesforce-contentの利用が推奨されます。
信頼できる情報源にもとづいて提示された選択肢

各ステップの出力に個別のフォーマットファイルを用意

各ステップには、出力に使われる表の構造を厳密に定めたテンプレートファイルが用意されています。AIエージェントは、文章で書かれた指示よりも、具体的なテンプレートのほうに確実に従います。フォーマットファイルをパイプラインのロジックから分離することで、ステップに手を加えずにフォーマットを繰り返し改善できます。
表形式で提示される評価基準

AIエージェントが自ら検証できるルールベースのスコア

リスク評価には、信頼度を表す数値が割り当てられます（低リスク = 85、中リスク = 55、高リスク = 25）。この数値に評価軸ごとの重み付け（信頼性20%、安定性20%、オペレーショナルエクセレンス20%、リソースの最適化15%、コストの最適化15%、公平性10%）を掛けて合計した値が、各選択肢の意思決定スコアになります。常に最もスコアが高い選択肢が推奨案になります。AIエージェントは数値を比較して結果を検証します。また、プロンプトでも、判断や推論を加えないよう指示されます。値を固定することで、曖昧さがなくなります。各リスクレベルに1つの固定値が割り当てられているため、リスクマトリックスからスコアが機械的に算出されます。

この例では、新しいWell-Architectedフレームワーク（英語）の方向性を踏まえて最適化したスコア帯を使用していますが、必要に応じて変更できます。
ユーザーの指示にもとづいて算出された意思決定の信頼度スコアの例

共有可能な出力

重要な意思決定は文書化しておく必要があります。新しく加わったチームメンバーにも、技術的な選択の理由を理解してもらわなければなりません。そのため、出力を永続的に保存できるように設計することが重要でした。このスキルには、簡潔な出力か詳細な出力かの選択肢を備えた、Markdown形式のArchitectural Decision Record (ADR)（英語）を採用しました。
意思決定の概要とMarkdown形式の出力

独自の意思決定スコアリングスキルを構築

このスキルは、他にも応用できる設計パターンです。希望するステップやスコアの算出方法、AIエージェントに応じて調整できます。

ステップ	考慮すべき点
1. パイプラインのステップを定義する	選択肢の提示に必要な前提情報と、スコアを算出するうえで重要となる評価軸を決定します。
2. 評価軸と重みを選択する	企業として最適化したい要素を明確にし、合計が100%になるように各評価軸の重みを設定します。
3. フォーマットファイルを作成する	出力を生成する各ステップについて、正確な構造を示すテンプレートを作成します��確認用のプロンプトも含めます。
4. スコア算出方法を記述する	リスクレベルごとのスコア帯を定義します。最も高いスコアの選択肢を推奨案とするというルールを明示します。
5. 外部データで裏付けを取る	ドキュメント参照用のMCPサーバーに接続するか、代替手段としてAIエージェントにWeb検索を実行させます。ドキュメントを返すMCPであれば、どれでも利用できます。このスキルでは、呼び出すツールではなく、検索の対象を指定します。意思決定の質は、情報源の質によって決まります。
6. 重要なルールは繰り返すようにしておく	特に重要な制約は、少なくとも2つのファイルに記述しておきます。AIエージェントは、会話が長くなるとルールを忘れることがあるためです。

さっそく始める

レポジトリ（英語）をクローンし、READMEの手順に従って、/decideとタイプした後に質問を入力してみましょう。

このスキルは、人からのフィードバックを繰り返し取り入れることを重視して作成しています。そのため、推論を長い文章として提示するのではなく、具体的で引用可能な記述に分解し、表形式で確認できるようにしています。こうしたスキルがあれば、意思決定の質が向上し、誤りに早く気づいて、次の担当者が活かせる形で意思決定を記録として残せます。

執筆者について

Dave Norrisは、Salesforceのデベロッパーアドボケイトです。技術的なテーマを、多様な読者に広くわかりやすく説明することに情熱を注いでいます。Salesforceで10年以上勤務し、現在、SalesforceとMuleSoftの認定資格を40以上保有。2013年に、Salesforce認定テクニカルアーキテクトの資格を取得しています。