tech-selection

技術選定 — ゲート式チェックリスト

技術を選ぶためのチェックリストであり、採点基準ではありません。中核となる考え方は、これらの基準は候補を絞り込むものであって、順位付けするものではないということです。原則に反する候補を除外します。候補とトレードオフを見える状態に保ち、現在の承認範囲を適用します。承認された、元に戻せる実装を選んで検証し、解決していないビジネス、製品、または好みに関するトレードオフはユーザーに返します。候補の数、所要時間、確信度を示す表現によって、誰が決定するかが決まるわけではありません。

以下の結果に至った場合、プロトコルを早期終了します。

1. ユーザーが選択する事項 — 承認が不足している、またはビジネス、製品、好みに関するトレードオフが真に未解決である場合です。根拠と推奨案を返します。
2. 未検証の完了主張 — 主張を保留し、承認された検証を実施して、残る受け入れ基準の不足があれば報告します。

これは対象外

• 調査レポート（deep-research を使用）、すでに確定したコードのデバッグやバグ修正、ベンダー間の価格比較には使用しません。いずれも技術を選ぶことではありません。
• 面接のフレームワークではありません。ユーザーが委任するのは実装であり、方針ではありません。調査して決定できる場合に、「どちらがお好みですか」と尋ねないでください。
• 採点基準ではありません。加重スコアや「勝者」の順位付けはありません。候補を絞り込んだ後、ビジネス上の基準を適用します。
• 自己認証型ではありません。「これが粗悪品ではない理由」の説明はこのスキルが作成しますが、自己承認ではなく、独立して確認できるものでなければなりません。
• コストを判断基準にしません。予算で決まるのは実行ティア（どのモデルを実行するか）であり、実行するかどうかではありません。ユーザー自身のプロジェクトで、コストを却下理由にしないでください。
• スコープを拡張しません。依頼されていない機能、フレームワーク、複雑さを追加しないでください。
• パッケージサイズを基準にしません。行数やバンドルサイズは品質の代替指標であり、品質そのものではありません。

実行プロトコル

軽量パス。 外部との契約がなく、小規模で元に戻せるローカル実装の場合は、ステップ 0、1、および該当するステップ 3 の軸を実行します。以下の簡易出力を使用し、結果が動作すると主張する前に、必要な承認済みの調査を実施します。バグ修正に含まれる JSON ライブラリの使用はこれに該当します。プロジェクトのストレージエンジンや外部向けのフィールド契約の変更は、所要時間が 10 分未満であっても、完全なプロトコルが必要です。所要時間が示すのは作業量であり、承認の有無ではありません。どちらのパスを適用すべきか判断できない場合は、完全なプロトコルを選んでください。どちらのパスでも、停止条件と現在のタスクに対する明示的な指示に従います。

ステップ 0 · 枠組みを定める

候補を比較する前に、次の内容を記述します。

1. この選択が実現する、明示されたビジネス上の成果。
2. 明示された障害モード — どのような観測可能な現象が、選択の誤りを証明するか。

ビジネス上の成果は、依頼文の内容ではなく、文脈から導き出します。単に「どの DB」と尋ねられても、それ自体には成果が示されていません。プロジェクトの決定ログ、ユーザーからの最近の修正指示、この選択によって後続作業の何が可能になるかを確認してください。導き出すための文脈がない場合は、作り上げず、その旨を明示してください。

チェックポイント：利用可能な文脈からビジネス上の成果を導き出せない場合 → これは選定タスクではなく、実行タスクです。このスキルを終了してください。ビジネス上の成果が「テストに合格する」や「パイプラインを完了する」と記述されている場合 → それは代理指標です。書き直してください。

ステップ 1 · 先行事例の棚卸し

固定順序: 内部・有償資産 → 外部のワールドクラス＋コミュニティソリューション → スクラッチからの構築（最後の手段）。各候補には、どのレイヤーから来たかをタグ付けします。

レイヤー 1 を探す場所: 既存の認証情報と有償サービスの機能カタログ、インストール済みスキル、現在のリポジトリに既存のパイプライン、プロジェクトの意思決定ログ、ユーザー自身がキュレーションしたお気に入り（favorites-search がインストールされている場合は最初に実行します）。レイヤー 1 を現在のリポジトリでの grep に限定しないでください。有償サービスやスキルに対してはヒットがゼロになり、狭い検索でのゼロは不存在を意味しません。

レイヤー 2 には最低限のカバレッジ要件があります。記憶だけに頼らず、検索ツールを使って何が存在するかを列挙してください。「検索して 2 件見つけた」はカバレッジではありません。実行した検索クエリを明示するか、利用可能な検索ツールがなくこれが記憶のみの棚卸しであることを明示してください。

チェックポイント: 最終的な推奨がレイヤー 1〜2 からの記録された理由なしにレイヤー 3（構築）に落ちる場合 → 闭门造车 としてフラグを立てます。レイヤー 1 のヒットゼロは、「構造的トークンで検索した」のか「記憶した名前で検索した」のかを区別しなければなりません。後者のヒットゼロは不存在を意味しません。

ユーザーが指名した候補。 ユーザーが特定の選択肢を指名した場合（「Redis と Postgres のどちらを使う？」「ベクターストアを追加すべき？」）、その選択肢は他の候補と同様に候補セットに入ります。同じ評価軸と判定の対象となります。フィルタリングを免除されることもなく（指名された候補は要件ではありません）、切り捨て可能でもありません（ユーザーが指名した候補を却下するには、他の候補とまったく同様に、評価軸と失敗モードを明示する必要があります）。ユーザーがちょうど 2 つの選択肢を指名した場合、それらが最小の候補セットとなります。棚卸しで浮上したレイヤー 1 またはレイヤー 2 の候補を追加し、その旨を記載してください。

ステップ 2 · 証拠のプローブ

取り込み、インデックス作成、ストレージ、またはバッチデータの選択については、references/batch-data-probes.md を読み込み、エンジンを比較する前に実際のコンシューマー契約から代表的なケースを導出してください。

証拠は何を立証するかでラベル付けします。観測された実行は測定された 振る舞いを証明します。現在の公式 API ドキュメントまたは検査済みソースは契約を 立証したり、互換性のない候補を除外したりできますが、実行時の使用可能性や ビジネス上の便益を証明することはできません。README やベンダーの主張だけでは、それらの主張は unknown のままです。 終了条件: 候補ごとに、手法をまたいで最大 2 回の試行。2 回失敗 → 「これは今はできない」とし、未測定の主張は unknown のままにします。

チェックポイント: 重要な主張はすべて、その証拠とスコープを明示します。実行時および ビジネス結果の主張には、対応する観測が必要です。ソース契約の 証拠を、観測された結果として再ラベル付けしてはなりません。

ステップ 3 · 各候補のフィルタリング

意思決定の評価軸をお読みください。各候補について、評価軸ごとに判定を示します: pass / fail（失敗モードを明示）/ unknown（プローブが必要）。

コア評価軸での fail は候補を排除します。references/scoped-criteria.md の C クラス基準での fail は排除しません — その候補に対する「宣言された選好に反する」注記として記録し、続行します。候補を生存者セットから除去するのは、コア評価軸の失敗のみです。

チェックポイント: unknown は pass ではありません。unknown を抱える候補は ステップ 4 の生存者セットに入りません。このステップから「勝者」を出力しないでください。

ステップ 4・生き残った候補の選別 — 中核となるゲート

• 生き残った候補が 0 件：どの軸がどの候補を退けたのか、その軸が誤っていたのか、候補セットが不完全だったのかを報告します。unknown と fail を区別し、停滞しているプローブと回復条件を明示します。ユーザーしか提供できない情報を尋ねる前に、実行可能で許可されたプローブを実行します。生き残った候補を捏造してはいけません。
• 生き残った候補が 1 件以上：references/delegation-contract.md を読みます。保守性や関連する業界慣行を含め、現在の承認状況と結果を確認します。許可された可逆的な実装では、根拠に基づいて選択し、代替案とトレードオフを保持したうえで、必要な検証を実行します。ユーザーが決定権を持つ選択が未解決の場合は、候補とトレードオフ、推奨案を 1 つ提示し、その選択に依存するアクションのみを停止します。却下した候補を黙って除外してはいけません。

チェックポイント：どの候補が、どの軸によって格下げされたのかを出力で示せますか？ 示せない場合、ゲートの実質が失われています。

ステップ 5・自己防衛スロット

完全なプロトコルによる結論には、「これが粗悪品ではない理由」を説明する段落が必要です。ただし、このスキル単独で自己認定してはいけません。軽量ルートでは、短い出力の中に、理由と根拠を明記します。

チェックポイント：自己防衛の記述にある各文は、根拠またはその根拠の範囲内にある軸の判定に基づいていますか？ 一般論（例：「成熟したライブラリである」）は無効です。

ステップ 6・不可逆な対象を網羅する

リリース後に修正できない対象を確認します。テレメトリ／イベント、フィールドとエクスポート形式、外部との契約、取り消せない外部アクションが該当します。いずれかが存在する場合は、v0 から網羅します。この軸は単一シナリオの根拠に基づくものです。選択によってリリース成果物が生じる場合に適用し、内部的な変更や元に戻せる変更には適用しません。また、不可逆な対象のない作業に対して基準を引き上げるために使ってはいけません。

チェックポイント：不可逆な対象を明示的に列挙するか、「なし」と明記してください。記載がなければ、確認されていません。元に戻せるローカルな変更は、このステップの対象になりません。

ステップ 7・完了宣言

「検証しました」と「そう主張しています」を区別します。完了を示す文にはすべて、実際に何を実行し、何を確認したかを続けて記載します。

チェックポイント：エージェントが実行できる、許可されたチェックを実行します。人による受け入れは別に明記してください。確認していない受け入れは未確認のままにし、完了の主張に含めてはいけません。また、すでに許可されている検証や成果物の提出を妨げてはいけません。

出力形式

軽量出力： 業務上の結果と反証条件、先行技術のレイヤー、選択したローカル実装とその理由および承認、必要なプローブの結果または unknown を示します。完全なマトリックスや、使用しない Steps 4〜6 のフィールドを求めずに、関連する代替案が見える状態にしてください。

完全なプロトコル出力： 以下のフィールドを出力します。実際の検証結果と人による受け入れ状況を、判断分岐とともに含めてください。

1. 業務上の結果と失敗モード（Step 0）。
2. 候補テーブル（Steps 1〜3）— 各候補にレイヤータグ、軸ごとの判定（pass／fail／unknown）、各 pass の根拠となるプローブ名、またはソース契約の判定を裏付ける権威あるソースの証拠を記載します。unknown を含む候補は、隠さず明示します。
3. 生存候補の降格記録（Step 4）— 降格した候補ごとに、どの軸によって除外されたか、および失敗モードの名称を記載します。候補が降格していない場合は、"no candidate eliminated" と記載し、すべての条件を満たした軸を列挙します。
4. 判断分岐（Step 4）— 次のいずれかを正確に1つ宣言します。
   • authorized implementation：選択した生存候補、代替案、トレードオフ、承認、および Step 5 の自己防御を記載します
   • user-owned choice → STOP：候補、トレードオフ、および推奨案を1つ記載し、不足している判断／承認と、保留する依存アクションを明示します
   • 0 survivors：原因が軸の誤りか、候補セットの不足かを診断します
5. 自己防御（Step 5）— 各文をプローブまたは軸の判定に結び付けます。選択した実装または推奨案について記載し、生存候補がない場合は、架空の勝者を擁護せず、診断を引き継ぎます。
6. 不可逆な対象の一覧（Step 6）— 見つかった対象、または "none" を記載します。省略しないでください。

停止条件

Stop 1 · 複数候補間の人によるトレードオフ判断

現在の承認範囲では、業務、製品、または好みに関する選択がユーザーに委ねられている場合、出力には次を含めます。

• 生存候補それぞれ
• そのトレードオフ（何にコストがかかり、何を断念するか）
• 理由を添えた推奨案を1つ

ユーザーが選択を確定する前に、その選択に依存する処理を実行しないでください。却下した候補とその理由も見える状態にし、根拠のない順位付けを作らないでください。生存候補が複数あるだけでは、ローカルで可逆な実装に対する承認が再び有効になるわけではありません。新たなスコープ、外部への約束、不可逆なアクションには、生存候補が1つだけの場合でも、それぞれ実際の承認が必要です。後から得られた事実や指示によって適用可能性が変わらない限り、以前の回答を再利用してください。

Stop 2 · 未検証の完了主張

エージェントは承認済みのプローブを実行し、実際の利用側／結果を確認します。テストの合格は、その結果の代わりにはなりません。成果物に人による受け入れが必要な場合は、具体的な結果と受け入れの証拠を提示し、確認されるまではその状況を未確認とします。裏付けのない完了主張は保留し、独立して承認済みの作業を続行し、進行が妨げられている場合は不足している条件を正確に示してください。

エージェントのオーケストレーション

委任する前に、オーケストレーション契約を読んでください。

参考資料

ファイル	読むタイミング
判断軸	Step 3 — 中核となるフィルター
バッチデータのプローブ	Step 2 — 取り込み／インデックス作成／ストレージの正確性、増加、増分処理、復旧
スコープ別の基準	Step 3 — 補足基準とクラスの扱い
却下モード	提案前 — セルフテストで草案を確認
委任契約	Step 4 — 判断の所有者を確認するとき、委任の前、またはスコープ境界を解決するとき

境界のクイックリファレンス

見かけ上の矛盾を解決する前に、解決済みのスコープ境界を読んでください。