結論：Claude Codeはライブラリ選定・技術調査の「調べもの」を一気に短縮できる。ただしAIが返すバージョンやAPIは古い・存在しないことがあるので、必ず公式ドキュメントと実コードで裏取りする前提で使うのが正解です。
この記事の要点：
- 要件と制約を先に言語化してから候補を洗い出すと、比較がブレない
- 機能・実績・メンテ状況・ライセンス・学習コストの5軸で候補を並べる
- Claude Codeには「公式情報を根拠に」「実コードベースとの相性を試す」「小さくPoC」「ADRで記録」までやらせる
対象読者：新機能に着手する前に「どのライブラリ・技術を使うか」を調べるエンジニア・テックリード・PM。
今日できること：下のプロンプト例をコピーして、いま迷っている技術選定をそのまま流してみる。
新しい機能に取りかかるとき、コードを書く前の「どのライブラリを使うか」「この技術で要件を満たせるか」の調査に、地味に時間が溶けていませんか。GitHubのStar数を眺めて、Issueを漁って、ドキュメントを行き来して……。正直、この比較検討フェーズは退屈なわりに、ここでの判断ミスが後の負債に直結します。
Claude Codeは、この「調べもの」を会話とコード操作の両面から手伝えるツールです。ただしAIの返すライブラリ情報・バージョン・比較は誤りうるので、使い方には作法がいる。この記事では、要件整理からADRでの意思決定記録まで、実際に手元で回せるプロンプト付きの技術調査ワークフローをまとめます（記載は2026年6月時点の情報です）。
大前提：AIの技術調査は「下書き」、裏取りは公式と実コードで
最初に一番大事なところを書きます。Claude Codeに「Aライブラリと Bライブラリ、どっちがいい？」と聞くと、それっぽい比較表をすぐ返してくれます。便利です。でも、ここに罠があります。
大規模言語モデルは、学習データのカットオフ以降のリリースを知らないし、知っていても細部を取り違えます。具体的には次のような誤りが起きます。
- バージョンの取り違え：すでに非推奨になったAPIを「現行の使い方」として提示する
- 存在しないAPIの捏造（ハルシネーション）：実在するライブラリに、実在しないメソッド名・オプションをもっともらしく付ける
- 実績・採用状況の誇張：「業界標準」「広く使われている」を裏付けなしに言い切る
- ライセンスの誤認：MITだと言われた実際はデュアルライセンス、というケース
だから本記事の全プロンプトは、「Claude Codeの出力＝そのまま採用、ではなく一次情報で確認すべき下書き」という前提で使ってください。バージョン・API・ライセンス・実績は、必ず公式ドキュメントとリポジトリ、そして実際に動かしたコードで確認する。Claude Codeには公式ページを根拠として引かせ、出典URLを出させるのがコツです。Anthropic公式も、Claude Codeを使う際は出力の検証を前提に組み込むことを推奨しています。
ステップ1：要件と制約を先に言語化する
候補を並べる前に、まず「何を満たせばよいか」を固めます。ここを飛ばして「いいライブラリ教えて」と聞くと、AIは一般論を返すだけで、自分のプロジェクトに合わない候補が混ざります。
要件は、機能要件と制約条件を分けて書くのがポイントです。次のような項目を埋めます。
- 達成したいこと：このライブラリ/技術で何を実現するか（例：CSVを大量にストリーム処理したい）
- 機能要件：必須機能と「あれば嬉しい」機能を分ける
- 制約条件：言語・ランタイムのバージョン、対応OS、既存スタックとの互換、許容ライセンス、バンドルサイズなど
- 非機能要件：性能、メンテ頻度、コミュニティの活発さ、商用利用の可否
- 除外条件：絶対に避けたいもの（例：GPLは社内方針でNG）
これをClaude Codeに整理させるプロンプトがこちらです。プロジェクト直下で実行すれば、既存の依存関係（package.jsonやpyproject.tomlなど）を読み込んだうえで制約を補完してくれます。
このプロジェクトで「[やりたいこと]」を実装するための技術選定をしたい。
まず候補を出す前に、要件と制約を整理してほしい。
- このリポジトリの依存関係・言語バージョン・ランタイムを読んで、
暗黙の制約（互換性・ライセンス方針など）を洗い出して
- 機能要件は「必須」と「あれば嬉しい」に分けて
- 非機能要件（性能・メンテ状況・学習コスト）も列挙して
- まだ私が決めていない論点があれば、質問として返して
結論を急がず、確認すべき前提を先に出してください。ここで「質問として返して」と頼むのが効きます。AIが勝手に前提を埋めて突っ走るのを止め、こちらが意思決定すべきポイントを明示させられるからです。
ステップ2：候補の洗い出しと5つの比較軸
要件が固まったら、候補を洗い出して比較表にします。比較軸は、案件によって増減しますが、最低限この5軸は押さえたい。
- 機能：要件をどこまでカバーするか。欠けている機能は自前実装が必要か
- 実績：採用事例、ダウンロード数、本番運用の事例。GitHub Star数だけで判断しない
- メンテ状況：直近のコミット日、Issue/PRの応答速度、メンテナの数。放置プロジェクトは将来の負債
- ライセンス：MIT/Apache-2.0/GPL/デュアルなど。社内方針・商用利用と矛盾しないか
- 学習コスト：ドキュメントの質、APIの分かりやすさ、チームの既存知識との距離
Claude Codeにはこの5軸で表を作らせます。ただし前章のとおり、出力はそのまま信じない。数字や日付には「不確かなら不確かと書け」と指示しておくと、ハルシネーションが目に見えやすくなります。
「[やりたいこと]」の候補ライブラリを3〜5個挙げて、
以下の5軸で比較表にしてほしい。
| 軸 | 内容 |
| 機能 | 要件カバー範囲と不足点 |
| 実績 | 採用状況（数値は不確かなら「要確認」と明記） |
| メンテ状況 | 直近のリリース時期の目安（不確実なら明記） |
| ライセンス | ライセンス名（必ず後で公式で確認する前提で） |
| 学習コスト | ドキュメントの質とAPIの分かりやすさ |
各候補について、公式ドキュメント・リポジトリのURLを併記して。
あなたの記憶が古い可能性がある項目には ⚠️ を付けて、
私が一次情報で確認すべき箇所を明示してください。「⚠️を付けて」という一言で、AIが「ここは自信がない」と自己申告してくれます。完全ではありませんが、検証すべき箇所の当たりがつきます。
ステップ3：Claude Codeで素早く調べる（公式を根拠にさせる）
比較表のドラフトができたら、いよいよ裏取りです。ここがClaude Codeの本領。WebFetchやMCP連携を使って、公式ドキュメントを実際に取得させ、「記憶」ではなく「いま取得した一次情報」を根拠に答えさせます。
たとえば候補ライブラリの最新バージョンとライセンスを確認する手順は次のとおりです。
- 候補それぞれの公式ドキュメントURL・リポジトリURLをClaude Codeに渡す
- 「このURLを取得して、最新の安定版バージョンとライセンスを引用付きで答えて」と頼む
- AIの記憶と取得結果がズレていたら、取得結果を優先させる
- API設計が要件に合うか、公式のコード例を読ませて評価させる
次のURLを実際に取得して、内容を根拠に答えてほしい。
あなたの事前知識ではなく、取得したページの記述を優先すること。
- [候補Aの公式ドキュメントURL]
- [候補Aのリポジトリ（ライセンスファイル）URL]
知りたいこと：
1. 現在の安定版バージョン（取得ページに記載があれば）
2. ライセンス（LICENSEファイルの記述で確認）
3. 「[必須機能]」に対応するAPIが存在するか、公式のコード例を引用して
記載が見つからない項目は「ページに記載なし」と正直に書いて。
推測で埋めないでください。「ページに記載なし」と書かせるのが地味に重要です。これがないと、AIは空欄を埋めようとして推測（＝ハルシネーション）に走ります。MCPでGitHubやドキュメントサイトと接続しておくと、リポジトリのIssueやCHANGELOGまで踏み込んで調べられて、メンテ状況の判断材料が増えます。
さらに踏み込むなら、Claude Codeに自分のコードベースを読ませて「この候補は既存スタックと相性がいいか」を評価させます。大規模なリポジトリでも、Claude Codeはコード全体を俯瞰して、既存の設計や依存と矛盾しないかを指摘できます。コードベース全体の把握のさせ方は、大規模コードベースを理解させる手順の記事が参考になります。
ステップ4：小さく試す（PoCで検証）
表の上で「良さそう」でも、実際に動かすと別の顔を見せるのが技術選定の常です。第1候補に絞ったら、最小構成のPoC（概念実証）を作って検証します。ここは机上の調査では絶対に見えない部分です。
PoCで確かめたいのは、だいたい次の4点。
- 本当に要件を満たすか：表上の「対応」が、自分のユースケースでも成立するか
- 既存スタックに乗るか：ビルド・型・依存の衝突がないか
- 体感の使い心地：APIの素直さ、エラーの分かりやすさ
- 性能の肌感：想定データ量で許容範囲か
Claude CodeにPoCを書かせるときは、いきなり本実装させず、Plan Modeで計画を立てさせてから着手すると安全です。何をどう作るかを先に確認できるので、的外れなPoCに時間を使わずに済みます。Plan Modeの使い方はPlan Mode実践ガイドにまとめています。
第1候補に [ライブラリ名] を選んだ。これでPoCを作りたい。
まずPlan Modeで、検証したい以下4点を確認できる
最小構成のPoCの計画を立ててほしい：
1. [必須機能] が実際に動くか
2. このリポジトリの既存スタック（[言語/FW]）に乗るか
3. APIの使い心地（サンプルを1つ動かす）
4. [想定データ量] での性能の肌感
実装は計画に合意してから。
使うAPIは推測せず、公式ドキュメントで確認した呼び出し方にして。
動かして詰まったら、エラーをそのまま報告して。PoCで詰まった点や「思ったより遅い」「ここのAPIが使いにくい」といった肌感は、最終判断の決め手になります。むしろこの段階で気持ちよく落とせる候補が出てくれば、PoCは成功です。難しい設計判断を含むPoCでは、拡張思考（extended thinking）を使って深く考えさせると、トレードオフの整理が丁寧になります。
ステップ5：意思決定をADRで記録する
選定が終わったら、最後に「なぜそれを選んだか」を残します。これをやらないと、半年後に「なんでこれ使ってるんだっけ？」となり、誰も触れない技術が居座ります。記録の定番フォーマットがADR（Architecture Decision Record）です。
ADRは、1つの意思決定を1ファイルで記録する軽量な手法です。最低限、次の要素があれば十分機能します。
- タイトル：何を決めたか（例：CSV処理ライブラリにXを採用）
- ステータス：提案中／承認済み／廃止など
- コンテキスト：どんな要件・制約があったか
- 決定：何を選んだか
- 理由：比較軸ごとに、なぜそれが勝ったか。落とした候補と落とした理由も
- 影響：この決定で生じるトレードオフ・将来の懸念
ステップ1〜4のやりとりは、すべてこのADRの材料になっています。Claude Codeに、これまでの調査ログをADRにまとめさせれば一発です。
これまでの技術選定（要件整理・比較表・PoCの結果）を、
ADR（Architecture Decision Record）形式で1ファイルにまとめて、
docs/adr/ に [連番]-[テーマ].md として保存してほしい。
含める要素：
- タイトル / ステータス（承認済み）
- コンテキスト（要件と制約）
- 決定（採用した技術）
- 理由（5軸ごとの評価。落とした候補と落とした理由も）
- 影響（トレードオフ・将来の懸念）
PoCで実際に確認できた事実と、未確認の前提は区別して書いて。
誇張せず、後で読む人が判断を追えるように。ADRをリポジトリに残しておけば、後から参加したメンバーも経緯を追えますし、Claude Code自身も次の調査でこの記録を文脈として読み込めます。チーム横断の前提はCLAUDE.mdに、個別の意思決定はADRに、と棲み分けると運用が回ります。よく使う調査フローはスラッシュコマンド化しておくと、毎回プロンプトを書き直す手間も消えます。
よくある失敗と対策
最後に、技術調査でやりがちな失敗を実例ベースで挙げます。
- ❌ AIの比較表をそのまま採用 → ⭕ バージョン・API・ライセンスは公式と実コードで裏取りしてから採用する
- ❌ 要件を固めずに「おすすめ教えて」 → ⭕ 機能要件と制約を先に言語化し、質問させてから候補を出させる
- ❌ 表だけ見て第1候補を本実装 → ⭕ 最小PoCで「既存スタックに乗るか」「性能の肌感」を必ず確認する
- ❌ 選定理由を残さない → ⭕ ADRに「落とした候補と理由」まで書き、後から経緯を追えるようにする
どれも「Claude Codeが速いぶん、検証と記録を省きたくなる」ことから生まれる失敗です。速くなった時間を、裏取りとPoCに回す。これが技術選定でClaude Codeを使うときの基本姿勢だと思います。
まとめ：今日からできる3アクション
ライブラリ選定・技術調査は、Claude Codeで確実に速くなります。要件整理→候補比較→公式での裏取り→PoC→ADR記録、という流れに乗せれば、判断の質も上がります。鍵は「AIの出力は下書き、確定は一次情報と実コード」という線引きを崩さないこと。
- いま迷っている技術選定を1つ選ぶ：ステップ1のプロンプトで要件を整理させてみる
- 比較表に⚠️を付けさせる：AIが自信のない箇所を自己申告させ、そこだけ公式で確認する
- 選定結果をADRに残す：1ファイルでいいので
docs/adr/に書き、チームに共有する
次回は、PoCで作った検証コードをそのまま本実装につなげる「PoCから本番への橋渡し」を取り上げる予定です。より体系的にClaude Codeの調査・実装テクニックを学びたい方は、実践テクニック完全ガイドもあわせてどうぞ。
