ソフトウェアを作ることは、家を建てる過程に似ています。設計図を描き、資材を選び、骨組みを組み立て、内装を仕上げ、漏水がないか点検します。

この過程で最も時間を要するのは、レンガを積む行為ではなく、レンガをどこにどのように積むかを決め、正しく積まれたかを確認するプロセスです。Claude Code と Cowork は、この決定と確認の領域において、開発者と企画者の負担を軽減します。

この章は、これまでの第1章から第6章とは性格が異なります。コードを扱う章ですが、コーディング経験のない読者でも、要件定義書（PRD）の作成やテストケース文書の作成といった企画領域を追随できるよう、参入障壁を低く設定しています。一方、エージェントチームの運用やコードマイグレーションなど、開発経験が必要な領域については、概念理解に比重を置きつつ、実行については中級者以上の読者を対象に案内します。

1 エージェントチームを基盤とした並列作業

一人が四人分の仕事をこなさなければならない開発者の一日

ウェブアプリケーションを一つ作成すると仮定してみましょう。

ユーザーが見る画面（フロントエンド）を作成し、画面の背後でデータを処理するサーバー（バックエンド）を構築し、データを保存するデータベースを設計する必要があります。最後に、これら三つが適切に連携して動作するかをテストしなければなりません。

一人の人がこの四つの作業を順番に行う場合、前の作業が完了しなければ次の作業を開始できません。バックエンドが完成していなければフロントエンドでデータを取得できず、データベースの構造が確定していなければバックエンドのコードを書くことができません。この順次的なボトルネックが、開発期間を延ばす最大の原因です。

実際の企業では、この問題をチームで解決します。フロントエンド開発者、バックエンド開発者、データベース管理者、QAエンジニアがそれぞれ担当領域を並行して作業し、必要に応じて互いにコミュニケーションを取りながら調整します。エージェントチーム（Agent Teams）は、この人間チームの構造をAIで再現したものです。

「ナ エージェントチーム」とは何か

エージェントチームとは、複数の Claude コードインスタンス（同時に実行される個別の AI セッション）がそれぞれ独立した役割を担い、一つのプロジェクトを並列で実行する機能です。2026 年 2 月に Claude Ops 4.6 のリリースに伴い、研究プレビューの形態で公開されました。

以前にも「サブエージェント」という概念は存在していました。

サブエージェントは、メインエージェントが指示を出すと独立して作業を実行し、結果だけを返す方式でした。問題は、サブエージェント同士が互いに会話できない点でした。フロントエンドのサブエージェントがバックエンドのサブエージェントに「API のアドレスが変わったのでコードを修正してください」と直接伝える方法がありませんでした。すべてのメッセージはメインエージェントを経由する必要があり、このボトルネックにより、複雑なプロジェクトでは互いのコードが衝突する事態が頻発しました。

エージェントチームはこの構造を変革しました。チームメンバーのエージェント同士がメッセージを直接やり取りできるようになりました。共有タスクリストを通じて、誰がどのような作業を担当しているかを確認し、一つのタスクが完了すると、次のタスクを自ら取得します。チームリード役のエージェントが全体を調整しますが、実務的なコミュニケーションはメンバー同士が直接行います。

[知っておいてください] エージェントインスタンスとは、一つの Claude コードセッションを指します。各インスタンスは独自のコンテキストウィンドウ（AI が一度に記憶できる情報の範囲）を持ち、独立して動作します。Claude Ops 4.6 は、インスタンスあたり 100 万トークン（約 75 万語）のコンテキストウィンドウをサポートしているため、大規模なコードベース全体をアップロードして作業を行うことが可能です。

エージェントチームはどのように活用するか

(1) 基本的な使い方: エージェントチームのアクティブ化と最初の実行 エージェントチームは実験機能のため、別途有効化する必要があります。

① クロードコードの設定ファイル (settings.json) を開きます。

② 以下の一行を追加します。「CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS: "1"」

③ 設定を保存し、 Claude コードを再起動します。

④ ターミナルで以下のように指示します。「このプロジェクトの README.md ファイルと全体のフォルダ構造を分析し、セキュリティレビュー担当者およびコード品質レビュー担当者の 2 名のエージェントチームを作成して、コードレビューを実行してください。」

⑤ クロードがチームリーダーの役割を自ら引き受け、2 名のチームメンバーエージェントを生成します。ターミナルには各エージェントの活動ログが表示されます。

⑥ チームメンバーエージェントがそれぞれコードを分析し、発見した問題をメッセージで互いに共有します。チームリーダーが結果を統合して最終的なレビューレポートを生成します。

(2) 応用例：tmux によるエージェントごとの画面分離 tmux（ターミナル多機能化ツール）を事前にインストールしておくと、各エージェントの作業画面を分割して同時に観察できます。

① tmux がインストールされた状態でエージェントチームを実行すると、画面が複数のパネルに分割され、各エージェントのターミナルが個別に表示されます。

② Shift キーと方向キーを押して特定のエージェントのパネルに移動し、そのエージェントに対してのみ個別の指示を出すことができます。

「フロントエンドエージェントよ、先ほど作成したログインページのボタン色を青から紺色に変更してください。」

③ 当該エージェントが指示を受け、修正を行い、変更事項をチームメンバーに通知します。

(3) 実戦活用：ブログプラットフォーム構築プロジェクト 小規模なブログプラットフォームを構築するシナリオです。

① プロジェクトフォルダに要件定義文書を用意します。（PRD の作成方法は、この章の第 2 節で取り扱います。）

② クロードには以下のように指示します。

「このPRDを読み、バックエンドAPI担当、フロントエンドUI担当、データベーススキーマ担当、テスト作成担当で構成されるエージェントチームを作成してください。バックエンドエージェントはNode.jsとFastifyを用いてREST APIを実装し、フロントエンドエージェントはReactでUIを実装してください。データベースエージェントはまずPostgreSQLのスキーマを確定し、他のエージェントと共有してください。テストエージェントは各APIエンドポイントに対するユニットテストを作成してください。」

③ クロードがチームを編成し、作業を分担します。データベースエージェントがスキーマを確定すると、バックエンドエージェントとフロントエンドエージェントがそのスキーマを基準に同時にコードを作成します。

④ 作業が進行する間、チームリードが進行状況を要約して示します。衝突が発生した場合は優先順位を判断して解決します。

エージェントチームを活用する際に知っておくべきこと

エージェントチームはトークン消費量が多くなります。各メンバーが独立した文脈ウィンドウを維持しながら互いにメッセージをやり取りするため、単一のエージェントで同じ作業を行う場合と比較してコストが4〜7倍に増大する可能性があります。単純なスクリプト作成やファイル整理のような作業にエージェントチームを使う理由はありません。

エージェントチームが効果を発揮する状況は明確です。フロントエンド、バックエンド、データベース、テストなど複数の階層を同時に扱うプロジェクト、異なる仮説を同時に検証する必要があるデバッグ、大規模なコードレビューなど、並列探索が実質的な価値を生む場合です。

もう一点。エージェントチームが生成したコードは個々の部分では清潔に見えても、全体システムの文脈において予期せぬ衝突を引き起こす可能性があります。あるエージェントがパフォーマンスのために導入したキャッシング構造が、別のエージェント

が作成したリアルタイム同期ロジックと衝突するといったケースです。エージェントがコードを記述する速度は速くなりましたが、そのコードが全体システム内でどのように機能するかを判断する責任は依然として人間にあります。

このような問題が発生した場合

(1) エージェントチームを作成したが、1 通のメッセージを送信しただけでセッションが終了する場合は、settings.json にエージェントチームの設定が正しく保存されているか確認してください。二重引用符とコロンの位置が正しいか確認し、Claude のコードを完全に終了してから再起動してください。

(2) チームメンバーのエージェントが同じファイルを同時に編集してコードが破損する場合は、プロンプトでファイルの所有権を明示してください。「各エージェントは担当フォルダのファイルのみを編集し、他のエージェントのファイルは読み取り専用とする」と指示することで、競合を減らすことができます。

(3) トークン使用量が予想よりも大幅に多い場合は、チームメンバー数を減らしてください。3 人で十分な作業に 5 人を投入すると、調整コストが増大するだけです。エージェントチームの作業には、Pro プランよりも Max プランの方が適しています。

2 ソフトウェア要件定義書およびアーキテクチャ文書化

「決済機能付きのアプリを作って」という依頼が失敗する理由

AI にコードを書かせる際、最も頻繁に起こる失敗は AI の能力不足ではなく、指示の曖昧さに起因します。「決済機能付きのプロジェクト管理アプリを作ってほしい」と伝えると、AI は無数の空白を自ら埋めます。決済手段はカードか振込か、ユーザー認証はメールかソーシャルログインか、プロジェクト管理の単位はチームか個人か。AI が補完した仮定が利用者の意図と異なる場合、結果は誰も望まないものとなります。

要件定義書（PRD：Product Requirements Document）は、この空白を事前に埋める文書です。何を作るのか、誰のためのものか、成功の基準は何か、今回は行わないことは何かを明確に記述します。PRD の品質がプロジェクトの成否を左右します。

私が Claude Code で作る PRD はどのようなものか

Claude Code の計画モード（Plan Mode）を活用すれば、AI はコードを一行も書かずに、分析と設計にのみ集中します。頭の中に浮かぶ断片的なアイデアを入力すると、AI が体系的な質問を投げかけて隙間を埋め、その結果を数十ページにわたる企画書として整理します。

最終的な成果物には、サービスの目的と成功基準、主要なユーザージャーニー、機能要件と非機能要件（パフォーマンス、セキュリティ、可用性）、データベーススキーマ（テーブル間の関係、データ型、制約条件）、システムアーキテクチャ（技術スタック、インフラ構成、認証体系）、そしてテストシナリオが含まれます。

PRD を作成してみましょう

(1) 基本利用：アイデアから質問リストを抽出する

① Claude コードターミナルを開き、計画モードに切り替えます。

② 以下のように入力します。

「中古品取引アプリを作りたいです。位置情報検索、チャット、エスクロー決済が核心です。コードを書く前に、プロジェクトに関する仮説を減らすために、明確化のための質問を 10 個以上投げてください。」

③ クロードが以下のような質問を提示します。「位置ベース検索の基本的な半径は何キロメートルに設定しますか？」「チャットで画像送信をサポートしますか？」「エスクロー決済の手数料率はいくらにしますか？」「会員登録はメール認証方式ですか、それともソーシャルログインですか？」「販売者認証手続きは必要ですか？

④ 各質問に答えます。

⑤ クロードはすべての回答に基づいて PRD 草案を生成します。

(2) 応用例：データベーススキーマと API 仕様まで含める

① 基本使用で生成された PRD 草案を確認した後、追加指示を入力します。

「この PRD をもとに、データベーススキーマを Prisma 形式で設計してください。User、Product、Transaction、Chat、Review の各テーブルを含め、各関係性とインデックスを明記してください。また、主要な API エンドポイントを OpenAPI 形式で整理してください。」

② クロードが Prisma スキーマファイルと OpenAPI 仕様を生成します。

③ 生成されたドキュメントを開き、内容を精査します。

(3) 実戦活用：PRD をエージェントチームの実行指針として活用する PRD の真の価値は、この文書がコーディングの起点となる点にあります。

① PRD が完成したら、Claude コードセッションを初期化します。コンテキストウィンドウに過去の対話が混在すると混乱を招くためです。

② 新しいセッションで、以下のように指示します。

「このフォルダにある PRD.md ファイルと schema.prisma、openapi.yaml を読み、その文書に従ってエージェントチームを構成し、アプリを実装してください。バックエンドは Fastify、フロントエンドは React、データベースは PostgreSQL を使用します。」

③ エージェントチームは PRD を「実行指針書（ソース・オブ・トゥルース）」として作業を開始します。

AI が作成した PRD をそのまま使用してはならない理由

AI が作成した PRD は出発点であり、最終版ではありません。AI は論理的に隙のない構造を構築するのが得意ですが、ビジネスの文脈における微妙な差異を完全に理解することはできません。韓国のエスクロー決済規定、個人情報保護法におけるデータ保管要件、対象顧客の年齢層に応じた UX の嗜好といった現実的な制約は、人間が必ず確認する必要があります。

レビューの順序は、次のように設定するのが良いでしょう。製品責任者が目標と範囲を確認し、エンジニアが技術的な実現可能性を検討します。セキュリティ担当者が認証、暗号化、ログポリシーを検証し、運用担当者がデプロイとモニタリングの体制を確認します。優れた設計書とは、一度で完成する文書ではなく、レビューを通じて決定を明確に残す文書です。

非開発者でも取り組める領域

PRDの作成は、コーディングの経験がなくても十分に可能です。サービスのアイデアを言葉で説明し、AIの質問に答えるプロセスは、ビジネス感覚の領域です。Coworkのデスクトップインターフェースでも同様のプロセスを実行できるため、ターミナルに馴染みのない読者には、Coworkから始めることをお勧めします。

このような問題が生じた場合

(1) PRDがあまりにも一般的で、自プロジェクトに合っていないと感じる場合、明確化の質問ステップを飛ばして直接PRDを要求すると、以下のような結果になります。まずAIに質問を投げかけ、具体的に回答を得た後に文書を作成させることで、品質を向上させることができます。

(2) 生成されたデータベーススキーマに必要なテーブルが欠けている場合、「監査ログ（Audit Log）、通知（Notification）、ファイル添付（Attachment）テーブルを追加してください」といったように、欠落している要素を具体的に指定します。

3 コードマイグレーションと自動テスト

技術的負債という見えない負債

技術的負債（Technical Debt）とは、古いコードが積み重なって生じる見えないコストのことです。新機能を追加するたびに予期せぬ場所でエラーが発生し、新しい開発者が合流すればコードを理解するだけで数週間を要し、セキュリティパッチを適用するには依存関係の問題に直面します。そのため、企業は定期的にコードマイグレーション（既存のフレームワークを新しいフレームワークへ移行する作業）を実施します。

この作業は開発チームが最も嫌がる業務の一つです。新機能を開発するのではなく、既存の機能を維持しながら内部構造のみを変更する作業だからです。ユーザーの目に見える変化はありませんが、投入される時間とコストは莫大です。

Claude Code がマイグレーションを支援する仕組み

Claude Opus 4.6 の 100 万トークンという文脈ウィンドウは、数十万行に及ぶコードベース全体を一度に分析することを可能にします。従来の AI ツールはコードを細かく分割して入力する必要があったため、ファイル間の依存関係を見過ごしがちでしたが、今では全体構造を把握した上で変換計画を立てることができます。

マイグレーションは通常、以下の 4 つの段階を経て行われます。第一に、現在のコードの境界を特定します。ルーティング、ミドルウェア、認証、エラー処理、データベースアクセス、外部 API 呼び出しを分離します。第二に、現在の API 構造を OpenAPI または JSON Schema として固定します。第三に、新しいフレームワークの構造に合わせて再構築します。第四に、既存バージョンと新バージョンを並べて動作の違いを検証します。

Express から Fastify への移行

(1) 基本利用：マイグレーション分析レポートの生成 ① 既存の Express プロジェクトフォルダを Claude Code に接続します。② 以下のように指示を出します。

「このプロジェクト全体を分析してください。Express の app.get、app.post パターンを使用するすべてのルートを特定し、ミドルウェアチェーンをマッピングし、データベースクエリがどこで実行されるかを整理してください。コードを修正せず、Fastify へ移行する際のリスクを 1（低）から 5（高）まで評価した移行分析レポートを作成してください。」

③ クロードがプロジェクトをスキャンし、全ファイルの相互参照関係とリスク要因を分析したレポートを生成します。

(2) 応用事例：段階的移行の実行

① 分析レポートを確認した後、リスクの低いモジュールから移行を開始します。

「リスク 1〜2 と評価されたルートから Fastify 形式へ変換してください。Express の req、res オブジェクトを Fastify の request、reply オブジェクトに置き換え、各ルートに JSON Schema ベースのリクエスト検証を追加してください。」

② クロードはこれらのファイルを変換します。この際、単なる機械的な置換ではなく、Express のミドルウェア方式と Fastify のプラグイン方式の構造的差異を反映させます。

(3) 実戦活用：自動テストの生成と検証

コードを移すことと同じくらい重要なのは、移したコードが正しく動作しているかを確認することです。

① 以下のように指示します。②「変換された各 Fastify ルートに対して、単体テストを作成してください。正常なリクエスト、不正なパラメータ、認証失敗、リソース不存在、サーバーエラーのシナリオを含めてください。Fastify の inject 方式を用いて、ネットワークポートを開かずにテストできるようにしてください。」

② クロードは各エンドポイントに対するテストコードを生成します。

③ 生成されたテストを実行し、通過したかどうかを確認します。「今作成したテストをすべて実行してください。」

④ クロードがテストを実行し、失敗した項目があればその原因を分析してコードを修正します。このプロセスはすべてのテストが通過するまで繰り返されます。

E2E(エンドツーエンド)テストまで必要であれば、Playwright(ブラウザ自動化ツール)を連携します。「Playwrightを使用して、ユーザーがログインし、商品を検索し、カートに追加し、決済するまでの一連の流れをテストするE2Eテストコードを作成してください。」

AIが生成したテストの限界

AIが生成したテストは、コードの現在の動作をそのまま検証します。現在の動作自体にバグがある場合、そのバグを正常とみなすテストが作成される可能性があります。そのため、AIが生成したテストコードも人間がレビューする必要があります。「このテストが検証する動作が、私たちが意図した動作と一致しているか」を確認するプロセスは自動化できません。

過去の開発者が残した不合理に見えるロジックが、実際には特定の運用環境のバグを回避するための解決策だった可能性があります。AI はこうした背景の歴史を知らずにコードを整理してしまう恐れがあります。移行において何を保存すべきかを判断するのは人間の役割です。

このような問題が発生した場合

(1) 移行中に「Cannot find module」エラーが繰り返される場合、依存パッケージが新しいフレームワークと互換性がない可能性があります。Claude に「package.json の依存性リストを分析して、Fastify と互換性がないパッケージを見つけてください」と指示してください。

(2) すべてのテストが通過するにもかかわらず、実際のサービスでエラーが発生する場合、テストでカバーしきれていないシナリオが存在することを意味します。運用環境の実際のデータパターンやネットワーク遅延などの条件をテストに反映させる必要があります。

4 UI/UX ウェブデザインおよび Figma 同期

デザイナーと開発者の間の古くからの溝

デザイナーがピグマ（Figma、ウェブベースのデザインツール）で精巧に作成したデザイン案が、開発者のコードとして実装されると、微妙に異なってしまいます。余白が4ピクセルずれたり、フォントの太さがセミボールドではなくボールドで適用されたり、影の透明度が変化したりします。デザイン案を開発者に引き渡すプロセスは「ハンドオフ（Handoff）」と呼ばれますが、この区間が製品開発において最も摩擦の大きいポイントの一つでした。

AIはこのハンドオフにおける摩擦を軽減しています。3つの方向からアプローチします。

ピグマMCP連携とは何か

MCP（Model Context Protocol）は、AIが外部ツールやデータとやり取りするための通信規格です。ピグマがMCPサーバーを提供したことで、Claudeのコードがピグマのキャンバス上のデザイン情報を直接読み書きできるようになりました。2026年2月17日に公開された「コード・トゥ・キャンバス（Code to Canvas）」機能により、双方向の同期が可能となっています。

Figma MCP サーバーはスクリーンショットのピクセルだけを眺めているわけではありません。コンポーネントの階層構造、色コード、フォントサイズ、余白の数値、デザイントークン（デザインの基本単位を定義した値）といった構造的な情報を読み取っています。

さあ、Figma と Claude Code を接続して実際に使ってみましょう

（1）基本使用：Figma MCP サーバーの設定

① Figma デスクトップアプリを最新バージョンに更新します。

② Claude Code のターミナルで次のコマンドを入力します。

claude mcp add --transport http figma https://mcp.figma.com/mcp

③ Claude Code で/mcp コマンドを入力し、Figma サーバーが接続されているか確認します。

④ Figma で認証を求められたら、「Allow Access」をクリックしてください。

(2) 応用例：Figma デザインをコードへ変換する

① Figma で変換したいフレーム（画面単位）を選択します。

② Claude コードに Figma のリンクを貼り付け、以下のように指示します。

「この Figma デザインを分析して、React コンポーネントに変換してください。Tailwind CSS を使用し、レスポンシブブレイクポイントを適用してください。デザインに定義された色コードとフォントサイズをそのまま反映してください。」

③ Claude は Figma MCP を通じてデザインの構造的情報を取得し、React コンポーネントのコードを生成します。

④ 生成されたコードをローカルサーバーで実行し、デザイン案と比較します。

（3）実戦活用：コードから Figma への逆方向転送

この機能が双方向同期を実現する核心です。開発者がコードで作成した UI をピグマのキャンバスへ送り、デザイナーが編集可能なフレームとして受け取ることができます。

① クロードのコード上でローカルサーバーを実行した状態で、以下のように指示します。

「私のアプリのローカルサーバーを開始し、現在の画面をキャプチャして新しいピグマファイルへ送信してください。」

② クロードがブラウザウィンドウを開き、キャプチャツールバーを表示します。ページ全体、特定の要素、複数の画面を連続してキャプチャできます。

③ キャプチャが完了すると、クラウドがピグマファイルのリンクを提供します。このリンクを開くと、キャプチャされた画面が編集可能なピグマフレームとして変換されています。

④ デザイナーが Figma で色や余白を修正すると、Claude Code がその変更を検知し、コードに反映できます。「Figma 内のこのフレームの変更を確認し、変更された部分のみコードに反映してください。」

知っておくべき制約事項

Figma MCP サーバーの一部機能は特定の条件下でのみ動作します。Code to Canvas 機能は現在、Claude Code、OpenAI Codex、VS Code のみでサポートされています。Figma のプランも、Dev または Full シート、Organization または Enterprise プランが必要です。API 呼び出しにはレート制限があるため、大量のフレームを一度に変換すると処理速度が遅くなる可能性があります。

AI が生成する UI コードの視覚的精度は向上していますが、アクセシビリティ基準を自動的に満たすわけではありません。スクリーンリーダー（視覚障害者用画面読み上げプログラム）との互換性、キーボードナビゲーション、色対比比などの詳細は、人間が別途検証する必要があります。ドラッグ＆ドロップ、無限スクロール、複雑なフォーム検証などのインタラクションロジックについては、AI が生成したコードの品質にばらつきがあります。

デザインの見た目自体は AI が迅速に作成できます。しかし、ユーザーの指先が感じる反応の速さ、スクロール時の画面の呼吸感、エラーメッセージが伝えるトーンなどは、依然として人間が手直しすべき領域です。

MA 実装は 3 つの段階で行います

一度にすべての機能を導入しようとすると、チームが疲弊してしまいます。最初の段階では、デザイン案をコードに変換する基本的な流れを習得します。2 番目の段階では、Figma MCP を接続して、デザイン文脈（色、余白、コンポーネント階層）を AI に提供します。

3 番目の段階では、Code Connect（Figma のデザインコンポーネントとコードリポジトリの実際のコンポーネントを接続するツール）を設定し、AI が新しいコンポーネントを考案するのではなく、チームがすでに使用しているコンポーネントを活用できるようにします。秩序立てて進める方が、結局はより迅速です。

このような問題が発生した場合

(1) Figma MCP サーバーを接続したにもかかわらず、generate_figma_design ツールが表示されない場合、以前に接続した Figma MCP インスタンスが残っていると競合が発生します。既存の接続を解除し、Claude コードを再起動してから再度接続してください。Figma プラグインを通じてインストールする方法が最も安定しています。

claude plugin install figma@claude-plugins-official

(2) ピグマでコードへの変換結果が元稿と大きく異なる場合は、スクリーンショットのみから推測するのと、MCPを通じて構造を読み取るのでは結果が異なります。MCPが正常に接続されているかを確認し、/mcp コマンドで確認した上で、プロンプトに「ピグマ MCP からデザイン文脈を取得して変換してください」と明記してください。

(3) 「コードからキャンバスへ (Code to Canvas)」機能が動作しない場合、この機能はリモート MCP サーバー (https://mcp.figma.com/mcp) を通じてのみサポートされています。ローカル MCP サーバー（デスクトップアプリの Dev Mode MCP サーバー）のみが接続されている状態では、コードからピグマへ送る機能は動作しません。リモートサーバーを別途接続してください。

本章で取り上げた 4 つの領域はそれぞれ独立した機能ですが、実際のプロジェクトでは一つの流れとして連携します。

PRD で要件を定義し、エージェントチームがコードを実装し、自動テストが品質を検証し、ピグマの同期がデザインとコードの隔たりを埋めます。AI がコードを書く速度は人間よりも速いです。しかし、何を作るべきかを決定し、作成された結果が事業の文脈に合致しているかを判断するのは、画面の前に座る人の役割として残されています。機械が構築した骨格の上に、私たちの組織独自の判断と経験を重ねること。それがこれらのツールを正しく使う方法です。