はじめに
最初に断っておく。この記事は技術決定を記録するADRの話でも、既存依存ライブラリの監査の話でもない。「これを採用すべきか」という意思決定を裏付けるための評価プロセスを速くする話だ。
技術選定の失敗パターンは大体同じだ。「GitHubスターが多いから」「みんなが使ってるから」というヒューリスティックで決めるか、POCを1つ作って1週間かけて評価するが他の候補と比較しないまま決定するか、どちらかになりやすい。もう一つ最近増えているのが「AIに聞いたらこれを勧められた」をそのまま採用するパターンだ——これが意外と危ない。
複数候補をPOCで比較する——1午後で4フレームワーク実装
エージェントフレームワークの採用を検討したあるエンジニアは、Claude Codeを使って「OpenAI Agents SDK」「Claude Agent SDK」「Google ADK」「AWS Strands」の4つを1午後で実装した。同一の機能要件（マルチエージェントのオーケストレーション、ツール連携）を4フレームワークで試し、コード量・API設計の直感性・デバッグのしやすさを実地比較した。
従来なら1つのPOCに1週間、複数候補の比較に数週間かかっていた作業が、比較の起点を1日で作れる。
プロンプトのテンプレートはこうなる。
以下の要件を [フレームワーク名] で実装するPOCを作って。
要件: - 機能A: [説明] - 機能B: [説明] - 評価したい観点: コード量の少なさ、型安全性、デバッグのしやすさ
実装後に「このフレームワークの強みと弱み」を箇条書きで整理して。 同じ要件を[競合フレームワーク名]で実装した場合との コード量・記述量の比較もして。
注意点がある。POCでうまくいっても本番規模・負荷・運用では異なる問題が出ることが多い。1午後で作ったPOCは「どのフレームワークが自分たちの要件に合いそうか」を絞り込むためのものであり、本番評価の代わりにはならない。
「AIの推薦」を鵜呑みにしない——多次元評価マトリクスの作り方
AIに技術選定を相談した際の落とし穴を体験したエンジニアの話がある。Timofey Bugaevskyは「TypeScriptをあらゆる場所で使うべきか」とAIに聞いたところ推薦された。批判的な質問を5つ投げてみると、AIはその全部に同意してしまった。
AIは学習データに豊富に含まれる技術を「最適解」と誤認識する傾向がある。JavaScriptエコシステムはマーケティングコンテンツが最も多いため、AIの推薦が偏りやすい。Claude Codeを「推薦者」として使うのではなく、「評価補助ツール」として使う設計が必要だ。
具体的には、評価軸を自分たちで先に決めてから、Claude Codeに採点させる。
[技術A]と[技術B]を以下の評価軸で比較するマトリクスを作って。
評価軸: 1. 学習コスト（チームのバックグラウンドを考慮） 2. 本番実績・採用事例数 3. パフォーマンス特性（[ユースケース]での期待値） 4. セキュリティ脆弱性の履歴（CVE数・更新頻度） 5. ライセンス互換性（[自社ライセンスポリシー]と照合） 6. コミュニティサイズ・維持者の活動度 7. AI支援開発との相性（Claude Codeが得意かどうか） 8. 採用市場でのエンジニア獲得のしやすさ
各軸を1〜5点でスコアリングし、判断の根拠を示して。 不確実な項目は「要確認」と明記すること。
出力されたスコアはあくまで「仮説の起点」だ。Claude Codeが出した評価は公式ドキュメントやGitHubで批判的に検証する。Claudeの知識カットオフ以降の最新バージョンについては知らない可能性があるため、特にバージョン依存の情報は別途確認が必要だ。
AI時代の新しい選定軸：「Claude CodeはこのライブラリをOn Distributionで知っているか」
2026年のarXiv論文が示した知見で、技術選定に新しい軸が加わった。AI Coding Proficiency（AIコーディング習熟度）という概念だ。
論文によると、同じライブラリペアでも評価が変わる。競合するライブラリペアの86%で「どのモデルが優れているか」がモデルによって異なる——つまり「Claudeが得意なライブラリ」と「GPT-4が得意なライブラリ」は違う。同じライブラリを別のLLMで使うと品質スコアが最大16ポイント変動し、組み合わせによっては生成コードの品質に84%の差が出ることもある。ライブラリの難易度や用途の違いが影響している。
Claude Codeチームがプロダクトの技術スタックをTypeScript + React + Inkで統一している理由として、Boris Chernyはこう語っている。"We wanted a tech stack which we didn't need to teach: one where Claude Code could build itself."（「教える必要のない技術スタック——Claude Code自身がClaudeを使って構築できるものを選んだ」）。Claude Codeの90%はClaude Code自身が書いているという。
チームで採用を検討するライブラリについて、Claude Codeがどの程度知っているかを確認するプロンプトが使える。
[ライブラリ名] を使ったコード生成例を10パターン作って。
その後、自分（Claude）がこのライブラリについてどの程度詳しく、 どの程度自信を持って実装できるかを率直に評価して。 「よく知らない」「最新バージョンでは変更があったかもしれない」 という場合は明示してほしい。
セキュリティリスクの事前評価も合わせて行いたい。2026年には実際にサプライチェーン攻撃によって広く使われているnpmパッケージに悪意あるコードが混入する事件が起きている。依存ライブラリのリスクをClaudeで事前評価するプロンプトはこう書ける。
[ライブラリ名] の採用可否を評価して。以下を調査して：
1. GitHub maintainer活動度（直近3ヶ月のcommit・issue対応頻度） 2. npm週次ダウンロード数の推移（成長or衰退傾向） 3. 既知のCVE・セキュリティアドバイザリー（severity別） 4. メンテナー数（1人依存のリスク） 5. 依存パッケージ数（サプライチェーンリスク） 6. 代替ライブラリ（このライブラリが廃止された場合の移行先）
Go/No-Go判定と、条件付きGoの場合は出口戦略も含めて。
POC結果をADRに連携して「意思決定プロセス」を組織に残す
技術選定の評価を終えたら、その結論と根拠をADRに記録することで「なぜこれを選んだか」が組織に残る。6ヶ月後に「なんでこのフレームワーク使ってるんだっけ」という問いに、誰でも即答できる状態を作れる。
以下のPOC評価結果をADR（Architecture Decision Record）として整理して。
評価した技術: [A], [B], [C] 採用決定: [A] 主な理由: - [理由1] - [理由2] 却下した技術とその理由: [B] は [理由], [C] は [理由]
ADR形式（Context / Decision / Consequences）で文書化して。
POC結果・評価マトリクス・却下理由を記録しておくと、あとから似たような技術選定が来たときに「以前はどう評価したか」が検索できる。選定プロセスの学習が組織に蓄積される。
まとめ
技術選定のボトルネックは「実装時間」から「評価フレームワークの設計」に変わった。Claude Codeで実装は速くなる。問題は「何を評価軸にするか」を誰が設計するかだ。
「AIに聞いたら推薦された」を鵜呑みにせず、評価軸を人間が先に設計してClaude Codeに採点させる。On Distributionかどうかの確認、セキュリティリスクの事前評価、POC結果のADR記録。この流れを一度通せば、次の技術選定で再利用できるテンプレートが手元に残る。
コメント