ハーネスエンジニアリングとマルチエージェントチームの概念

AIエージェントが実際のタスクを確実に動作させるためには、「何を指示するか」よりも「どのフレームワークの中で動かすか」が重要です。第1章では、なぜAIエージェントが必要なのかを見ました。本章では、ハーネスエンジニアリングの視点と、単一エージェントに頼るのではなく複数のエージェントがチームとして協働するマルチエージェントチームの基本構造について解説します。

出典: Claude Code公式ドキュメント — サブエージェント, ai-workspace-standardsリポジトリ, Faros AI — Harness Engineering, Anthropic — Building Effective Agents

エージェントとは何か

本章でハーネスエンジニアリングに踏み込む前に、「エージェント」を正確に定義しておきましょう。AIエージェントとは、目的を与えられたAIシステムであり、単純なチャットボットとは異なります。

チャットボットの仕事は単に「質問に答える」ことです。ユーザーがプロンプトを入力し、応答を生成し、会話が終われば何も残りません。エージェントは3つの点で異なります。

• 目的の永続性：エージェントには「役割」として定義された目的があります。会話が長くなっても、その役割（研究者、レビュアー、ライターなど）を見失うことなく一貫して動作します。
• ツールの使用：エージェントはテキストを生成する以上のことができます — ファイルの読み取り、コードの検索、コマンドの実行などが可能です。第4章では、toolsフィールドを通じたこれらツールの制御方法を解説します。
• 自律的な振る舞い：単一プロンプトに対する単一応答ではなく、エージェントは目標を達成するために複数のステップを自律的に実行できます。条件による分岐、エラー時のリトライ、結果の検証を自ら判断します。

プロンプト → コンテキスト → ハーネス — どうしてここに至ったのか

ハーネスエンジニアリングは突然現れたものではありません。AIへのアプローチにおいて3つの段階が積み重なった結果です。各段階は前の段階を置き換えるものではなく、「前の段階だけでは不十分」と判明した後に、その上に重ねられました。

料理の例えで3つの段階を理解するのが簡単です。プロンプトエンジニアリングは「料理人にどう注文の言葉を伝えるか」、コンテキストエンジニアリングは「料理人にどんな食材とレシピを渡すか」、ハーネスエンジニアリングは「厨房そのもの — 検査手順、道具、衛生ルール — が毎回同じ品質を生み出すシステムを構築する」です。注文の言葉がどれほど上手でも、食材がどれほど良くても、厨房システムそのものが杜撰なら、結果は毎回不一致になります。

第1段階 — プロンプトエンジニアリング（2022〜2024年）

初期の関心は純粋に言語に関するものでした。結果の品質がリクエストの言い回しに大きく依存することが明らかになると、「より良いプロンプトの書き方」がコアスキルとして扱われました。この段階のAIは洗練されたオートコンプリートに近く、人間が各ステップで方向を誘導する必要がありました。

例えば、単に「このコードをレビューして」と頼むと、モデルはどの基準を使うべきか判断できず、曖昧な回答になります。一方、「この関数のエッジケース処理、命名の一貫性、パフォーマンスの問題を個別にレビューして」という具体的な指示は、劇的に良い結果をもたらします。この「何を言うかを洗練させる」というノウハウが、この段階のすべてでした。

第2段階 — コンテキストエンジニアリング（2024〜2025年）

モデルの性能が向上するにつれ、ボトルネックは「表現」から「情報の供給」へと移りました。モデルのコンテキストウィンドウに何を入れるべきか — 関連ファイル、プロジェクトルール、アーキテクチャの制約 — をキュレーションすることが重要になり、RAGやMCPなどのツールがこのプロセスを体系化しました。2025年9月、Anthropicはこれを「推論中に最適なトークン集合をキュレーション・維持する技法」と公式に定義しました。

プロンプトがどれほど良くても、モデルがプロジェクトのコーディング規約や既存の関数構造を知らなければ、間違ったスタイルのコードを生成します。コンテキストエンジニアリングは、コンテキストウィンドウにモデルが実際に必要なものだけ — リクエストに関連する少数のファイル、プロジェクトルール文書、過去の会話の要約 — を入れる技法です。情報が少なすぎると推測になり、多すぎると重要なものがノイズに埋もれます。

第3段階 — ハーネスエンジニアリング（2026年〜）

2026年現在の支配的なパラダイムです。モデル自体は生の知性に近く、その知性を実際に信頼できる自律的な振る舞いに変えるのがハーネスです。ツールオーケストレーション、検証ループ、コンテキスト/メモリ管理、ガードレール、可観測性 — この5つのレイヤーが揃って初めて、エージェントは「実際に仕事を任せられる」レベルに達します。「エージェント自体が難しい部分ではない — ハーネスが難しい部分だ」という言葉がこの時代を要約しています。

同じプロンプトと同じコンテキストが毎回異なる品質の結果を生むなら、実用にはなりません。ハーネスエンジニアリングは、モデルの回答そのものではなく、回答を取り巻くシステムを設計することです — 「この結果を自動的に検証する方法はあるか」「危険な操作（ファイル削除、決済の実行など）は人間の承認なしにブロックされているか」「何かが失敗したときに何が悪かったのかをログから追跡できるか」といった問いを投げかけます。

ハーネスの全体アーキテクチャ図

ハーネスエンジニアリングは、モデルとユーザーの間に位置する5層構造として捉えることができます。以下の図は、本ハンドブック全体を貫くアーキテクチャを一望できるものです — 次節で、この5層の各層がどの章で扱われるかを対応付けます。

ハーネスエンジニアリングとは

プロンプトエンジニアリングが「モデルにどんな言葉を与えるか」に焦点を当てるのに対し、ハーネスエンジニアリングは一歩引き、「モデルにどんなツール、ルール、検証メカニズムを通して作業させるか」を設計します。ここでの「ハーネス」という用語は、馬を制御するための馬具に由来しています — AIが好きな方向に走り出すのを防ぎ、定義された手順、ツール、権限の境界の中で予測可能に動くようにするフレームワークを指します。

実際には、このフレームワークはいくつかの具体的なメカニズムとして現れます：エージェントが呼び出せるツールのリストと、各ツールのリスクレベルに基づく承認ポリシー；特定のイベント（ファイル保存直後、タスク完了時など）で自動実行されるフック；定型的なタスク手順を標準化・再利用するスキル；そしてこれらすべてを組み合わせて複数のエージェントを固定順序・固定条件で実行するオーケストレーションスクリプトです。これらのメカニズムが蓄積されると、「同じリクエストを何回繰り返しても品質とフォーマットが揺れない」再現可能なAIワークフローが完成します。

具体例を挙げましょう。「このファイルを削除して」というリクエストが来たとき、ハーネスのないAIは即座に削除を実行する可能性があります。ハーネスのあるAIは違う動きをします：削除は「危険なツール」として分類され、実行前にユーザー承認を必要とするポリシーの対象となり；削除完了後はその事実がログに記録され；誤ったファイル削除を元に戻す手順（gitでのコミット前状態の確認など）すら用意されています。モデルの判断はどちらでも同じですが、結果の信頼性を決めるのは、その判断を取り巻く「安全メカニズム」の有無なのです。

単一エージェントの限界

すべての役割を単一エージェントに割り当てるのは最初は便利ですが、作業がスケールするにつれて3つの問題が顕在化します。第一に、コンテキストの過負荷：設計レビュー、コード執筆、テスト、ドキュメント作成をすべて1つのセッション内で順次処理すると、作業が進むにつれて初期のステップの詳細が薄れ、結果の一貫性が低下します。第二に、役割の衝突：自分のコードを自分でレビューするエージェントは、自分が書いた欠陥を見逃します — 著者とレビュアーが同じ人である場合と同じ問題です。第三に、並列性の欠如：独立したサブタスク（複数ファイルのリファクタリング、複数の視点からのレビューなど）であっても、単一エージェントが順次処理する必要があるため、合計時間が線形に増大します。

企業の組織の例えで理解するのが簡単です。ある新人に企画、開発、テスト、ドキュメントをすべて一度に担当させると、最初はコミュニケーションオーバーヘッドがなくて速く感じます — しかし業務量が増えると、その人の頭（コンテキスト）はカオスになり、自分のコードの欠陥を見落とし（役割の衝突）、3つの無関係なタスクを同時に処理できず（並列性の欠如）、ボトルネックになります。組織が企画者、開発者、QAを分割する理由は、まさにAIの作業も複数エージェントに分割する理由と同じです。

マルチエージェントチームは、この3つの問題を構造的に解決します：役割ごとにコンテキストを分離して各エージェントが自分の役割に集中し、著者と検証者を分離して独立した視点を確保し、相互依存のないタスクを並行実行して合計時間を短縮します。

マルチエージェントチームの構成要素

マルチエージェントチームは3つの主要な要素で構成されます。

オーケストレーター

全体タスクをステップに分解し、各ステップに適したスペシャリストエージェントを呼び出し、ユーザーの確認が必要なポイント（ゲート）で進行を一時停止する役割です。よく「PMエージェント」と呼ばれ、自らはコードを書かず、調整に専念します。

プロジェクトマネージャー（PM）に例えるとわかりやすいです。PMはコードを直接書きませんが、「このタスクをバックエンド開発者に、このタスクをQAに」と割り当て、重要な判断の前にはチームリーダー（ユーザー）に「これで進めてもよいですか」と確認してから次のステップに進みます。オーケストレーターも同じ振る舞いをします。例えば、「新しい機能を追加して」というリクエストに対し、オーケストレーター自ら「1) 設計レビュー → 2) 実装 → 3) テスト → 4) ドキュメント」に分解し、各ステップを担当エージェントにハンドオフします。

スペシャリスト

狭く明確に定義された責任を持つエージェント — 設計、実装、テスト、セキュリティレビューなど。各スペシャリストは明確に定義された入力と出力を持つため、オーケストレーターは「このエージェントに何を任せられるか」を容易に判断できます。

例えば、test-runnerスペシャリストは「テストを実行し、失敗項目を報告する」ことだけが責任です。新規コードの作成やアーキテクチャの変更はその仕事ではありません。責任をこのように狭く切ることで、オーケストレーターは「テストが必要ならtest-runnerを呼ぶ」と即座に判断でき、スペシャリストは自身の役割に集中してより正確な結果を生み出せます。

ハンドオフ契約

エージェント間で作業を引き継ぐ際に交換される情報の形式です。自然言語だけで引き継ぐと、次のエージェントがコンテキストを再推測しなければなりませんが、構造化された入力（JSONなど）で「このタスクの目的、範囲、事前成果物」を明記すれば、次のエージェントは直ちに作業を開始できます。

宅配の引き継ぎに例えるとわかりやすいです。「これをあそこに持って行って」と言うだけでは、受取人が住所、数量、注意事項を再確認する必要がありますが、送り状（追跡番号、受取人、数量、特記事項を記載した文書）を渡せば、受取人は直ちに配達を開始できます。ハンドオフ契約はエージェント間の「送り状」です。ライターが「このファイルをこの基準でこの形式でレビューして」と明示的にレビュアーに引き継げば、レビュアーは再確認することなく直ちに開始できます。

実際には、次のような構造化ドキュメントとして引き継がれます。

{
  "task": "Code Review",
  "agent": "reviewer",
  "scope": {
    "target_file": "src/api/handler.ts",
    "change_description": "Added auth middleware — JWT token verification logic"
  },
  "deliverables": {
    "from": "code-writer",
    "files": ["src/api/handler.ts", "src/auth/verify.ts"],
    "commit_hash": "a3f7c21"
  },
  "review_criteria": [
    "Security: is token expiration handled",
    "Error handling: is there a 401 response for invalid tokens",
    "Tests: were relevant tests added"
  ],
  "output_format": {
    "type": "structured_comment",
    "fields": ["pass_fail", "findings", "suggestions"]
  },
  "failure_conditions": [
    "Report immediately if target_file does not exist",
    "Mark as block if security criteria are not met"
  ]
}

この例では、task、scope、review_criteriaが「何をレビューするか」を定義し、output_formatが「結果をどの形式で返すか」を定義します。failure_conditionsはレビュー対象自体に問題がある場合の対応をカバーします。このように、ハンドオフ契約は目的、範囲、基準、形式、例外処理を明示的に定義し、次のエージェントが再確認なしで直ちに作業を開始できるようにします。

サブエージェントとは

前述のスペシャリストは概念であり、サブエージェントはその概念を実際のツール内で実装するメカニズムです。サブエージェントはメインセッションとは分離された独立したコンテキストウィンドウを持つヘルパーエージェントで、割り当てられた狭いタスクだけを処理し、結果を要約してメインセッションに返します。メインセッションの会話履歴にはサブエージェントの詳細なやり取りが蓄積されず、最終的な要約だけが保持されるため、§2で指摘した「コンテキスト過負荷」問題を構造的に軽減します。

事前定義 vs 動的生成

サブエージェントの取り扱いはツールによって異なります。Claude Code/Appは事前定義方式を採用しています。.claude/agents/にname.mdファイルを配置し、YAMLフロントマターでname（呼び出し時の識別子）、description（このサブエージェントを使用する条件）、tools（許可するツールのリスト、権限を最小化するため）、model（どのモデルで実行するか）を指定します。メインセッションはAgent（Task）ツールを通じてこの定義を呼び出し、subagent_type="name"を指定します。

一方、Antigravityは動的生成に近いアプローチです。事前にファイルを作成するのではなく、オーケストレーターに自然言語で目標を与えると、その場で必要な役割を構成・処理します。「reviewerというサブエージェントを呼び出す」というよりは、エージェントがその都度、タスクに合った役割を構築するイメージです。どちらのアプローチも最終的には同じ目標 — 「分離されたコンテキストで狭いスコープのタスクを処理する」 — を達成しますが、事前定義は再利用性と権限制御に強く、動的生成は柔軟性に強いという違いがあります。

サブエージェントを使うべき場面

すべてのタスクをサブエージェントに分割する必要はありません。適しているのは、境界が明確な（入力と出力がはっきりしている）タスクで、かつ反復的または並列化可能なもの — コードレビュー、テストの実行、ドキュメントレビューなどです。逆に、メインセッションと継続的にコンテキストを交換し続ける探索的な作業は、サブエージェントに切り出すとハンドオフのオーバーヘッドがかえって大きくなります。

オーケストレーションパターン

Anthropicが2024年12月の「Building Effective Agents」で示した5つのワークフローパターンが、実務で最も広く使われています：プロンプトチェーン（パイプライン）、ルーティング、並列化（セクショニング/投票）、オーケストレーター・ワーカー、評価者・最適化（検証後適用）。5つのパターンは排他的な選択肢ではなく、「タスク間に依存があるか」「サブタスクを事前に予測できるか」「検証が必要か」という判断基準に基づいて選択・組み合わせるツールボックスです。

• プロンプトチェーン / パイプライン。タスクを順序付けられた一連のステップに分割し、各ステップの間に検証ゲートを配置します。複数のアイテムを同時に流し込むと、アイテム同士が待ち合わせないパイプラインになります — アイテムAがステップ3にある間にアイテムBはまだステップ1にいられるため、全体のスループットが向上します。
  例：工場の組立ラインのようなもの。製品Aが塗装段階にある間に、製品Bはすでに組立段階にあります。「ドラフト → レビュー → 校正」の3つの文書を流す場合、文書1がレビューに移った瞬間に文書2のドラフトを開始できます。
• ルーティング。まず入力リクエストを分類し、その性質に適したスペシャリストエージェントまたはモデルにルーティングします。第5章のモデルティアリングはその典型例 — 簡単な質問は安価なモデル（haiku）に、困難で稀な質問は高性能なモデル（opus）に送り、コストと品質のバランスを取ります。
  例：顧客からの問い合わせが来たとき、分類エージェントがまず「これは単純なFAQか、複雑な技術的質問か」を判定し、前者を定型応答エージェントに、後者をより深い調査が可能なエージェントにルーティングします。
• 並列化。2つのブランチに分かれます。セクショニング（ファンアウト）は、複数の独立したサブタスク（例：4つの視点からのコードレビュー）を同時に複数のエージェントに渡し、結果を集約します — 合計時間は最も遅い単一タスクの時間に収束します。投票は、同じタスクを複数のエージェントに独立して繰り返させ、過半数または合意で1つの回答を選びます。
  セクショニング例：「このコードをパフォーマンス、セキュリティ、可読性、テストカバレッジの4つの視点から同時にレビューして」。投票例：3つのエージェントに同じバグの根本原因を独立して分析させ、2つ以上が同じ原因を指摘したらその結論を採用する — 過半数投票で1つのエージェントの間違いをフィルタリングします。
• オーケストレーター・ワーカー。§3で説明したチーム構造がまさにこのパターンです。作業の分割方法を事前に決めるのではなく、中央のオーケストレーターが入力に基づいて動的にその場で判断し、ワーカー（スペシャリスト）に委譲して結果を統合します。サブタスクを事前に予測できない複雑なタスク（多数のファイルにまたがるコード変更、複数の情報源を統合する必要のある調査）に特に適しています。§4bで解説する「動的チーム編成」はまさにこのパターンの別名です。
• 評価者・最適化 / 検証後適用。1つのエージェントがドラフトを作成し、独立したエージェント（または複数エージェントの合意）がそのドラフトに異議を唱え検証した後、初めて実際に適用されます。もっともらしいが間違った結果が通り抜けるのを防ぐメカニズムです。
  例：コードを修正する前に、独立したエージェントが懐疑的な立場から「この変更は本当に安全か」を再検討し、問題ないと判断された場合にのみファイルを実際に修正する。著者が自分の文章を推敲する際に、別の人が見落とした誤りに気付くのと同じ原理です。ただし限界もあります — 評価者自体が良い結果と悪い結果を区別できなければ、このループは進捗なしに回り続けることになります。

失敗時の対応 — リトライ、ロールバック、エスカレーション

上記のパターンはすべて「正常に終了した場合」を前提としていますが、実際にはサブエージェントが間違った結果を出したり、完全に失敗したりすることがあります。検証後適用は「実行前にフィルタリングする」メカニズムであり、実行後に問題が発見された場合の対応は別の問題です。典型的な対応方法は3つあります。

• リトライ。一時的なエラー（ネットワークタイムアウト、ツール呼び出しの失敗など）の場合は、同じタスクを再試行します。ただし、同じプロンプトを無限にリトライしても同じ間違いを繰り返すだけなので、通常はリトライ回数に上限を設定します。
• ロールバック。間違った結果がすでにファイルやリポジトリに適用されている場合、変更前の状態に戻します。第3章の「書き込みステップはgitで取り消せる範囲に留めるべき」という原則がここで真価を発揮します。コミットレベルで作業を分割しておかなければ、ロールバックは正確なポイントに着地できません。
• エスカレーション。リトライが失敗し続ける場合や、オーケストレーターにとって判断が本質的に曖昧な場合は、人間に委ねます。「3回失敗したら自動リトライを停止し、人間に報告する」という事前定義の上限がなければ、失敗し続けるタスクを永遠にリトライして時間とコストを浪費することになります。

動的チーム編成と多様なワークフロー

これまでオーケストレーター、スペシャリスト、ハンドオフ、オーケストレーションパターンを個別に解説しましたが、ハーネスエンジニアリングの真の力は、これらの要素が単一の固定された組み合わせにロックされていないことです。従来の自動化スクリプトはコードの中に順序と参加者をハードコードします — 「常にAの次にB、常にBの次にC」 — しかしハーネス上に構築されたマルチエージェントチームは、オーケストレーターがリクエストごとに「今回は誰が必要で、どの順序で」と新たに判断します。

チーム編成は固定ではない

同じチームでも、リクエストの性質に応じて異なる数と組み合わせのスペシャリストを呼び出します。「単にタイポを修正して」といった単純なリクエストでは、オーケストレーターはreviewerだけを呼び出して終わるかもしれません。「新しい機能を設計からデプロイまで」というリクエストでは、architect・code-writer・test-runner・security-monitor・docs-writerを順次（または一部並列に）動員します。ロスター自体（どのサブエージェントが定義されているか）が事前に固定されていても、特定のタスクで実際に動員されるのは毎回新たに決定されます。サッカーチームの全22人の登録メンバーは固定ですが、対戦相手と戦術に応じて毎回スタメン11人が新たに選ばれるのと同じです。

この柔軟性は、§3bで解説したサブエージェントの2つの実装アプローチにも繋がります。事前定義アプローチ（Claude Code/App）であっても、オーケストレーターは毎回動的に「今回はどの定義済みサブエージェントを呼び出すか」を選択します。動的生成アプローチ（Antigravity）ではさらに一歩進み、サブエージェントの存在そのものがその時のニーズに合わせてその場で構築されます。どちらの場合でも「タスクがチーム編成を決める」という原則が成り立ちます。

同じハーネス上に多様なワークフローを構築できる

ハーネスエンジニアリングが固定するのは骨格だけです — 「オーケストレーターがいて、スペシャリストを呼び出し、ハンドオフで情報を渡す」。その骨格の上に何段のパイプラインを構築し、何人の参加者で実行するかは、ドメインごとに全く異なる設計が可能です。第5章で解説するai-workspace-standardsのバリアントがこれを実証しています。同じハーネス原理の上に、co-developはPM、Architect、Designer、Code Writer、Test Runner、Security Monitorの6段階ガバナンスパイプライン、co-designは5段階の反復ワークフロー、co-deckは11段階のワークフロー — それぞれ全く異なる形に仕立てられています。ハーネスエンジニアリングのコアの利点は、単一の「正しいワークフロー」を強制するのではなく、ドメインが要求する段階数、参加者数、検証の厳格さに合わせてワークフロー自体を設計できることです。

これはまた、§4の5つのオーケストレーションパターン（プロンプトチェーン、ルーティング、並列化、オーケストレーター・ワーカー、評価者・最適化）が排他的ではなく、単一のワークフロー内で自由に組み合わせ可能であることも意味します。例えば、コードレビューワークフローでは、まず変更の小大を分類するためにルーティングを使用し、大きな変更の場合はオーケストレーター・ワーカーが影響ファイルを動的に分割して4つの視点から同時にファンアウトリビューし、結果をパイプラインで順次ドキュメント処理し、最後に評価者・最適化（検証後適用）が変更を実際に適用するかを決定する — 5つのパターンすべてを1つのフローに混在させることができます。

ツール横断的なハーネス — AGENTS.md

これまで解説したオーケストレーター、スペシャリスト、ハンドオフは、特定のツールに結びついた概念ではありません。問題は、各ツールがこのハーネスを異なる方法で設定していたことです。Claude CodeはCLAUDE.mdを読み、Cursorは.cursorrulesを読み、GitHub Copilotは.github/copilot-instructions.mdを読みます — 複数のツールを併用するチームは、同じ内容を各ファイルに重複して維持する必要がありました。

同じ内容（例：「常にnpm testでテストを実行し、src/legacy/フォルダは変更しない」）をチームが使うツールごとに（CLAUDE.md、.cursorrules、copilot-instructions.md...）コピーすると、ルール変更のたびにすべてのファイルを見つけて編集する必要があり、一つでも見落とせばそのツールを使う人は別のルールの下で作業することになります。これは、同じ契約を複数の言語に別々に翻訳して保持し、一部だけが修正されたときに版が食い違うのと同じ問題です。

AGENTS.mdは、この問題を解決するために2025年8月にOpenAI主導でGoogle、Cursor、Factoryなどの参加を得て作成されたオープン規格で、2025年12月にはLinux Foundation傘下のAgentic AI Foundationに寄贈されました。リポジトリのルートに単一のAGENTS.mdを配置するだけで、Codex、Claude Code（インポート経由）、GitHub Copilot、Cursor、Google Jules、Antigravityファミリーなど30以上のツールがセッション開始時にこれを読み取り、ビルド/テストコマンド、コードスタイル、アクセス禁止領域などの共通ルールを共有できます。

本ハンドブックが「4つのツールすべてをサポートする」と強調し続けている理由も、まさに同じ問題意識に由来します。チームがClaude Desktop Appを使ってもAntigravity Desktopを使っても、共通ルールをリポジトリルート（AGENTS.md）に置き、ツール固有の詳細設定（CLAUDE.md、GEMINI.mdなど）と分離しておけば、ツールを切り替えたり混用したりしてもハーネス自体は安定します。第5章で検討するai-workspace-standardsリポジトリは、この原理の実際の実装です。ルートのAGENTS.mdファイルがワークスペース内のすべてのエージェントの単一の信頼できる情報源（SSOT）として機能し、.agents/フォルダが.claude/や.gemini/と並んで、エンジンに依存しないコマンドとスキルを保持します。

次の章に進む前に、このチームに実際のツールを渡す際に必要な安全装置について解説します。第3章では、サブエージェントに対して何を許可し何をブロックすべきか、そして人間がどこで必ず確認しなければならないかを解説します。その後、第4章ではClaude Desktop App/Antigravity Desktopを中心に（Claude Code/Antigravity CLIの手順も併記して）、オーケストレーター、スペシャリスト、ハンドオフがツールごとにどう現れるかをハンズオンで構築します。