学びブログ

Learning Blog

競合サイトを調べ、特徴を比較し、自分のサイトの構成案まで一度に作る。AIへの依頼は短くても、内側では複数の仕事が混ざっています。調査の抜けを見つける仕事と、魅力的な見出しを考える仕事は、求める判断が違います。

Claude Codeの公式ドキュメントは、Dynamic Workflowsを、Claudeが書いたJavaScriptのスクリプトで複数のサブエージェントを調整する仕組みとして説明しています。計画を会話だけで管理する代わりに、分岐や途中結果をスクリプトへ置き、読み直して再実行できる設計です。公式：Dynamic Workflows

この記事では、架空の教室サイトの競合調査を題材に、分ける仕事、残す成果物、確認する条件を設計します。実際のワークフローを起動した記録ではありません。エージェントを増やすだけで正確さや費用が改善する、という主張もしません。

1．「誰が次を決めるか」に注目する

公式資料は、サブエージェント、Skills、エージェントチーム、ワークフローの違いを、計画を誰が持つかという観点で整理しています。ワークフローでは、実行の順序や中間結果をスクリプトで扱います。公式の組み込み例には、複数の観点から情報を調べて検証するdeep-researchがあります。公式：方式の違いと組み込みの調査

Web制作への応用として、まず考えたいのは「何人のAIを使うか」より、「調査から構成案へ進める条件は何か」です。資料がそろっていないのに構成を作ると、調査中の推測が、確定した見出しとして後へ流れる場合があります。

この表は本記事の設計例です。実在する製品の内部処理をそのまま図にしたものではありません。人が担当しても、AIを使っても、途中の成果物と次へ進む条件を決める考え方は利用できます。

2．調査範囲を先に絞る

架空の題材は、社会人向けの陶芸教室サイトです。目的は、体験講座のページで読者が比較したい情報を整理すること。自社で確定しているのは、平日夜の開催、少人数の指導、申込フォームの三点とします。料金と持ち物は未確定です。

比較対象は三つの架空ページA、B、Cだけにします。最初から「関連するすべての教室を調べて」とすると、どの時点で調査を終えたかを説明しにくくなります。今回の対象を決め、追加調査が必要なら、その理由と候補を別の欄へ残します。

集める項目は、対象者、開催条件、申込方法、掲載されている持ち物の説明です。掲載情報がない場合は空欄ではなく「記載を確認できず」とします。記載がないことと、サービスとして存在しないことは同じではありません。

比較の目的も固定します。自社の言い回しを競合へ似せることではなく、読者が判断するために必要な情報の候補を見つけることです。競合の実績や写真、顧客の声を、自社の素材として使うことは含めません。

対象ページを決めたら、担当ごとの調査項目を分けます。一人が対象者、一人が申込条件、といった項目別の分け方もあれば、ページAとページBを別々に読む分け方もあります。項目の意味が曖昧なまま分担すると、あとで同じ列へ異なる情報が入るので、記録の形式をそろえます。

3．中間成果物を、文章より先に決める

最初の成果物は長い調査レポートではなく、一行ずつ確かめられる確認表にします。「ページ・項目・記載内容・根拠の位置・確認状態」の五列が、この例の基本です。

たとえばAのページに「初回は道具を貸し出す」と書かれていたら、貸出の記載として残します。それを「すべて無料」と言い換えると、料金の意味を足してしまいます。文章を整える前に、書かれている範囲を保ちます。

検証する担当には、調査担当の結論だけを渡しません。記録した根拠も見られるようにします。結論だけを読んで賛成する仕事では、調査の見落としや言い換えのずれを見つけにくくなります。

対象は指定した三つの比較ページです。項目は対象者・開催条件・申込方法・持ち物に限定してください。各記録にURL、確認日、記載箇所を付け、記載がない場合は「確認できず」と残します。料金や実績を推測で補わず、構成案はまだ作りません。対象外のページが必要なら、必要な理由だけを別表へ出してください。

この指示文は独自の例で、公式の設定コードではありません。実際にツールへ渡す前に、対象URLと取得できる範囲を利用環境に合わせて確かめます。

作業の区切りには、確認表の件数だけでなく、状態の説明を残します。十二行埋まったから完成、という扱いでは、同じ内容を分割して行数を増やした結果も通ってしまいます。「対象の四項目について、記載あり・確認できず・未取得のどれかが分かる」ことを完了条件にします。

4．検証と構成提案を同じ仕事にしない

検証の工程では、①根拠にない意味を足していないか、②対象ページを取り違えていないか、③条件や例外を落としていないかを読み戻します。良い構成を考えることは、この段階の目標に含めません。

調査に問題があった場合は、その行を修正するか、未確認として残します。検証が難しいことを理由に、根拠のない一般論へ置き換えると、確認表の役割が薄れます。分からない点を見える形で残したほうが、次の判断に使えます。

構成提案へ進めるのは、競合の傾向と自社の条件を区別できた後です。たとえば比較対象に持ち物の説明があることから、自社にも同じ持ち物を指定することはできません。自社へ確認する質問として「持ち物の案内を掲載できますか」と残します。

構成案は「体験で何をするか」「誰のためか」「開催条件」「持ち物」「申込方法」といった候補を並べられます。ただし、候補と完成した本文は区別します。料金と持ち物が未確定なら、それぞれのセクションに必要な素材と確認担当を付けます。

構成担当へ渡す指示では、競合の表現をコピーしないことと、自社の承認済み情報だけで文章案を作ることを明記します。情報の候補を集める段階から、公開に使う情報を選ぶ段階へ、判断が変わる場所です。

5．再実行は、変わった材料に合わせる

途中結果を残す意味は、失敗したときだけではありません。自社の料金が決まった場合、比較対象をすべて調べ直す必要があるとは限りません。自社条件の更新を読み、料金に関係する構成と案内文を確認するほうが、変更の影響を追いやすくなります。

一方、比較対象のページが更新されたら、そのページの確認日と記録を更新します。以前の調査表に新しい確認日だけ付けると、実際に読んだ版が分からなくなります。元の記録と更新後の記録を分け、何が変わったかを残します。

再実行の範囲を絞ることは、必ず費用が下がるという意味ではありません。確認漏れを避けるために広く読み直す場合もあります。変更した材料と、その材料に依存する判断を結びつけて、今回どこを確認したかを説明します。

6．人数ではなく、確認できる成果物で評価する

並行作業は対象が多いときに便利ですが、同じ資料を何度も読み、似たレポートを大量に返すと、統合する担当者の負担が増える場合があります。最初は少数の対象と小さな確認表で、工程が役に立つかを見ます。

記録する指標は、完成までの時間だけではありません。根拠を読み直した件数、重複した指摘、条件の取り違え、未確認事項の見落としなども、独自の確認項目として残せます。数値を比較するときは、素材、モデル、設定、試行回数をそろえます。

AIが自分の返答を確認したという説明だけで、独立した検証が行われたとは判断しません。誰が何を読み直し、どの主張が残ったかを成果物で確かめます。これが見えない場合には、人が根拠を確認する工程を追加します。

今日の練習では、三つの架空ページを用意し、四項目の表を作るところまでで十分です。その後、根拠を読み戻す担当と、自社の構成を考える担当を分け、途中の表だけで引き継げるかを試してください。

Dynamic Workflowsを実際に使う場合は、利用可能なプラン、起動方法、権限、実行の管理を現在の公式資料と自分の画面で確認します。本記事は仕組みを応用した工程設計であり、製品の実行結果や処理速度を測定したレビューではありません。

情報確認：2026年10月13日。公式ドキュメントの確認日であり、機能の発表日を断定していません。図解、題材、確認表、依頼文は独自制作です。ワークフローの実行、料金・品質・速度の実測は未実施です。