Claude 学習
コースガイド（分割）

Building with the Claude API 第7章 — Anthropicアプリ・Claude Code・エージェントとワークフロー

Lesson: Anthropic apps（Anthropicのアプリ）

このモジュールでは、Anthropic自身が構築してデプロイした2つのアプリケーションを見ていく。それが Claude Code と Computer Use である。

Claude CodeとComputer Useはどちらもそれ自体で非常に有用だが、この2つを取り上げるにはもう一つ理由がある。Claude CodeとComputer Useはagentの完璧な実例であり、これらがどう動くかを理解することで、agentとは何か、効果的なagentをどう構築するかをより深く理解できるようになる、という位置づけである。

次のビデオではまず、Claude Codeのセットアッププロセスを進めていく。

Lesson: Claude Code setup（Claude Codeのセットアップ）

Claude Codeを見ていく。セットアップを行い、動作の仕組みを学び、いくつかの高度なユースケースも見ていく。

Claude Codeとは: ターミナルで実行されるプログラムで、幅広いコード関連タスクを支援してくれる、ターミナルベースのコーディングアシスタント。現在はターミナルCLIを中核としつつ、Web版・デスクトップアプリ・VS Code/JetBrains拡張・Slack統合・CI連携など複数のサーフェスでも利用できる。

Claude Codeが持つツール:

セットアップ手順（3ステップ）:

  1. Node.jsをインストールする。すでにNodeがインストール済みかもしれないので、ターミナルを開いて node --version を実行して確認する（npm help はnpmの使い方テキストを表示するだけなので、Node/npmの導入有無の確認には使えない）。
  2. Nodeがインストールされたら、npm install -g @anthropic-ai/claude-code コマンドでClaude Code自体をインストールする（単なる npm install ではカレントディレクトリの依存関係インストールになってしまうため、-g フラグとパッケージ名が必要）。なお現在の公式ドキュメントでは、npm経由のインストールは「Advanced installation options」に位置づけられる代替手段（Node.js 22以降が必要）であり、主要な推奨手順はNode.js不要のネイティブインストーラ（curl -fsSL https://claude.ai/install.sh | bash など、macOS/Linux/WSL向け）やHomebrew、WinGetになっている。
  3. インストールが完了したら、ターミナルで claude コマンドを実行する。これによりAnthropicアカウントへのログインを促される。

完全なセットアップガイドは公式Anthropicドキュメント（docs.anthropic.com）にある。この3ステップを各自で進め、完了したら小さなプロジェクトを一緒に見ていき、Claude Codeが実際に何をしてくれるのかを確認する。

Lesson: Claude Code in action（実践するClaude Code）

Claude Codeのハンズオン経験を積むため、講師が取り組み用の小さなプロジェクトを用意した。このレクチャーに添付されたzipファイルにプロジェクトのソースがある。zipをダウンロードし、内容を展開し、この新しいプロジェクトディレクトリの中でコードエディタを起動することが推奨される。

Claude Codeについて理解すべき重要なこと: プロジェクトの中身を見たりReadMeファイルに書かれたセットアップを進めたりする前に、まず理解してほしいことがある。Claude Codeは単にコードを書いてくれるだけのツールではない。もちろんコードを書くことは完全にできるが、それだけがClaude Codeの本質ではない。むしろ、Claude Codeはプロジェクトを一緒に手がけるもう一人のエンジニアとして捉えるべきである。通常のプロジェクトで行うあらゆるタスク——プロジェクトの初期セットアップから新機能の設計、デプロイ、サポートまで——をすべてClaudeに委任できる。このプロジェクトを進める中で、プロジェクトのセットアップ、新機能の計画、テストとコードの記述にClaudeを大いに活用し、さらに後で別のプロジェクトを使って、本番環境のエラーを自動的に発見・修正する方法も紹介する。

プロジェクトのセットアップをClaudeに任せる

エディタに戻り、ターミナルを開いて claude を実行しClaude Codeを起動する。最初の指示として、ReadMeファイルの内容を読み、そこに書かれたセットアップ手順を実行するようClaudeに依頼する。Claudeは様々なツールを使ってそのファイルを読み込み、一連のコマンドを実行する。新しい仮想環境を作成し、環境をアクティベートし、いくつかの依存関係をインストールする。

init コマンドとCLAUDE.mdファイル

セットアップが完了したら、Claudeにプロジェクトをより深く理解してもらうため init コマンドを実行する。これはClaude Code自体の中で実行するコマンドである。このコマンドを実行すると、Claudeは自動的にコードベースをスキャンし、プロジェクトの全体的なアーキテクチャやコーディングスタイルなどを理解する。完了すると、Claudeはその発見内容すべてを CLAUDE.md という特別なファイルに書き込む。以降Claudeを実行するたびに、このファイルは自動的にコンテキストとして含まれる。

なお、CLAUDE.mdファイルには Project・Local・User に加え、組織管理者が配布する Managed policy を合わせた4種類がある（Project・Local・Userについてはこの後すぐに参照が出てくるので、その時に詳しく説明する）。

init コマンドを実行するときには、Claudeに注目してほしい特定の領域について特別な指示を追加することもできる。実際に試してみると、講師は「MCPツールの定義について詳細なメモを含めてほしい」という特別な指示を加えて init を実行した。完了後、新しく生成されたCLAUDE.mdファイルの内容を確認すると:

このファイルは、以後Claudeに送るあらゆるフォローアップリクエストのコンテキストとして含まれることになる。

CLAUDE.mdの更新方法:

Project memory / Local memory / User memory: 例えば「関数の引数には常に適切な型を付けること（always apply appropriate types to function args）」という指示を # で追加すると、そのメモをどこに追加したいか尋ねられる。これがProject・Local・Userメモリが登場する場面である。講師の場合、このプロジェクトに関わる全員と共有したいメモだったため、Project memoryに追加した。追加後、CLAUDE.mdファイルの内容を確認すると、Code Styleのセクションの下か、あるいはファイルの一番下あたりに、追加したメモが反映されているのが見られる。

変更のコミット

この時点で、プロジェクトに新しいファイル（CLAUDE.md）が追加されており、このプロジェクトはGitで管理されている。通常であれば、ターミナルを開いてこの新しいファイルをGitにステージし、変更をコミットするところだが、それをClaudeに依頼した方がずっと速い。「すべての変更をステージしてコミットして」とClaudeに依頼すると、Claudeはコードベースに加えられたすべての変更を確認し、説明的なコミットメッセージを書いて、それらのファイルをコミットする。

Claudeの効果を高めるテクニック

次に、コードを書く際にClaudeの効果を高めるテクニックをいくつか紹介する。このプロジェクトに新機能を追加する題材として、WordドキュメントまたはPDFファイルを読み込み、その内容をMarkdownに変換する新しいツールをMCPサーバーに追加するというタスクを扱う（このプロジェクトは非常に小さくシンプルなMCPサーバーである）。

単純に「Word doc + PDF file to markdown conversion tool を作って」と直接指示することも当然できるが、その前に理解してほしいことがある。Claude Codeは「effort multiplier（努力の乗数）」だと考えてほしい（注: ここでの「effort」はユーザー側の努力を指す比喩表現であり、Claude Code / Claude API に実装されている公式のリクエストパラメータ Effort（low/medium/high/xhigh/max のレベルでClaude自身の思考・作業量を制御するもの）とは別物なので混同しないよう注意）。Claudeへの指示の出し方に少し努力を注げば、それに応じて大幅に良い結果が返ってくる。ここでは、Claudeにタスクへの取り組み方を指示する2つの異なるワークフローを紹介する。どちらも多少の努力を要するが、その分Claudeはより複雑な問題に取り組めるようになる。

ワークフロー1: 3ステップの「調査→計画→実装」

  1. 関連ファイルを特定して読ませる: コードベースの中で、取り組もうとしている機能に関連すると分かっている箇所を特定する。そのファイルを具体的に読んで分析するようClaudeに依頼する。プロジェクトにはToolsディレクトリがあり、その中にMath.pyファイルがある。これはすでに作られているツールの一例であり、ツールをどう実装するかのイメージをClaudeに与えるのに役立つ。また、バイナリデータをMarkdownに変換する非常に便利な関数 binary document to markdown を含む document.py ファイルも見せる。これらのファイルを読ませることで、Claudeはツールの書き方と実際の変換方法の両方について、より良いイメージを持てるようになる。
  2. 機能を伝えて計画を立てさせる: 構築したい機能をClaudeに伝え、解決策を計画するよう依頼する。具体的には、PDFまたはWordドキュメントへのパスを受け取り、ファイルを読み込み、内容をMarkdownに変換して結果を返す、Document Path to Markdown という新しいツールの実装を計画するよう依頼する。ここで重要なのは、まだコードは書かず、計画だけを立てるよう明示的に指示することである。これに対しClaudeは、この機能全体を実装するために必要となる複数のステップを含む、かなり詳細な計画を返してくる。
  3. 計画を実装させる: 最後に、この計画を実装するようClaudeに依頼する。Claudeはまず document.py ファイルを更新し（これは間違いなく正しい）、次に main.py ファイルを更新し（これも良い）、最後にこの新しいツールに関するテストを1本書く。そして、そのテストスイートを実行してテストが実際に通ることを確認する。サマリーメッセージの中でClaudeは、存在しないファイルや未サポートのファイルタイプに対するエラーハンドリングも追加したと報告してくる。これは講師が機能の説明の中で明示的に依頼していなかったことだが、適切な対応だった。

ワークフロー2: テスト駆動開発（TDD）ワークフロー

別のアプローチとして、TDDワークフローを紹介する前に、Claudeが直前に書いたコードをすべて取り除く（変更をstashする）。これでその機能に関連するものが何もないクリーンな状態に戻る。

TDDワークフローも事前に多少の努力を要するが、Claudeの効果を劇的に高める。手順:

  1. 関連するコンテキストを見せる（前と同様）。
  2. コードを書く前に、この機能に関連してどんなテストを書けるかをClaudeに考えさせる。
  3. その中から最も関連性の高いテストを選び、実装するようClaudeに依頼する。
  4. 動作するテストが揃ったら、テストが通るまでコードを書くようClaudeに依頼する。

同じ機能（ハードドライブ上のドキュメントを読み込みMarkdownに変換するツール）に対してこのアプローチを実演する。

まとめ: Claude Codeは本当に「effort multiplier」である。非常にシンプルな指示だけでもClaudeは最善を尽くしてくれるが、こちら側にも少し努力を注ぐことで、Claudeの効果を劇的に高めることができる。

Lesson: Enhancements with MCP servers（MCPサーバーによる機能拡張）

Claude Codeの最も興味深い側面の一つを紹介する。Claude CodeにはMCPクライアントが内蔵されている。つまり、MCPサーバーをClaude Codeに接続することで、その機能を劇的に拡張できるということである。

これを実演するため、これまで取り組んできたMCPサーバーにClaude Codeを接続する。先ほど Document Path to Markdown というツールを作成した。このツールをClaude Codeに公開することで、PDFやWordドキュメントの内容を読めるようになる——つまり、Claude Codeの能力を動的に拡張しているということである。

セットアップ手順:

  1. ターミナルに戻り、Control-Cで実行中のセッションを終了する。
  2. claude mcp add を実行してMCPサーバーをClaude Codeに追加する。まずMCPサーバーの名前を入力する（名前は何でもよい。今回はドキュメントに関連するサーバーなので documents と名付けた）。
  3. 最後に、サーバーを起動するために使うコマンドを入力する。今回の場合は uv run main.py である。
  4. これを実行し、claude でClaude Codeを再び起動する。

これで、先ほど作成したツールを実際にテストできる。テストディレクトリの中に fixtures フォルダがあり、その中にデモファイルが2つ（Wordドキュメントと PDFドキュメント）ある。どちらもMCPに関するごく短いドキュメントを含んでいる。このどちらかのファイルの内容をMarkdownに変換するようClaudeに依頼すると、先ほど作成したツールを利用してくれることが期待される。実際、少し上にスクロールして確認すると、うまく動作しており、そのファイルの内容が実際に表示された。

MCPサーバーを消費できることの意義: このMCPサーバーを消費できる能力は、Claude Codeに信じられないほどの柔軟性を加え、実に興味深い開発の可能性を切り開く。例えば:

これらはほんの一例に過ぎない。自分の開発ワークフローをどう強化できるか、時間をかけて考える価値は十分にある。

Lesson: Agents and workflows（agentとworkflow）

このモジュールでは、workflowとagentに焦点を当てる。さっそく、これらが何なのかを理解しよう。

定義: workflowとagentは、Claudeが単一のリクエストでは完了できないユーザータスクを扱うための戦略である。実は、このコースを通じてすでにworkflowとagentを作ってきている。例えば、tool useを学んだとき、タスクをClaudeに与え、提供されたツールを使ってどう完了するかをClaudeに委ねていた。これはagentの一例だった。

workflowかagentかを決める経験則:

このレッスンとこの後の数レッスンは、100%workflowに焦点を当てる。いくつもの実例を示していく。

最初のworkflow例: 金属部品の画像から3Dモデルを生成するアプリ

ユーザーが金属部品の画像を画面にドラッグ&ドロップできる小さなWebアプリを作っていると想像する。このアプリの目標は、その画像から何らかの方法で3Dモデルを構築することである。最終的にユーザーには STEPファイル を返す（STEPファイルに馴染みがなくても問題ない。STEPファイルは3Dモデルを共有・伝達するための業界標準的な方法にすぎない）。つまり、画像から3Dモデルを作っているということである。

3Dモデリングにあまり詳しくなくても、少しの助けと時間があれば、このアプリの実装方法を思いつけるはずである。想定される実装手順:

  1. ユーザーがアップロードした画像をClaudeに渡し、その物体を詳細に記述するよう依頼する。
  2. その記述を別途Claudeに渡し戻し、CAD QueryというPythonライブラリを使ってその物体をモデリングするよう依頼する（CAD Queryは3Dソリッドモデリングを行えるPythonライブラリで、このプロセスからSTEPファイルを出力できる）。
  3. Claudeが最初からこのモデルを完全に正確に作れるとは限らない。そこで、初期モデルを構築したらエラーチェックのステップを追加してもよい。レンダリング結果を1枚の画像として作成し、その画像を再びClaudeに渡して、元の画像とのレンダリング結果の一致度を尋ねる。
  4. Claudeがレンダリング結果に大きな問題があると判断したら、ステップ2に戻ってもう一度部品のレンダリングを試みるようClaudeに依頼する。
  5. このプロセスを繰り返し、最終的に元の部品の正確なモデルにたどり着くことを目指す。

ここで重要なのは、このステップの流れ全体を事前に想像できるという点である。このプロセス全体を事前に設計し、それを実装するコードを簡単に書き出せる。実際、講師はこれとほぼ同じものを以前に実装したことがある。すべてのステップを事前に明確にリストアップし詳細化できるため、これをworkflowと呼ぶ。workflowとは、非常に具体的な問題を解決することを目的とした、Claudeへの一連の呼び出しであり、そのステップが何であるべきかを事前に正確に把握しているものだと定義する。

evaluator optimizer

このモデリングworkflowは、evaluator optimizerと呼ばれるworkflowの一例である（注: 本ガイドでは分かりやすさのため、以下このワークフロー内の役割を「プロデューサー」「グレーダー」と呼ぶが、Anthropic公式の "Building effective agents" およびclaude-cookbooksの実装ではそれぞれ generator・evaluator と呼ばれている。特に「グレーダー」という呼び方は、本コース前半で扱った eval のグレーダー——モデルの出力を採点する仕組み——とは別の概念なので混同しないよう注意）。考え方:

重要な補足: workflowを識別すること自体は、それ単体では何も生み出さない。それらを実装する実際のコードは、依然として自分で書き下す必要がある。workflowについて議論する理由、そしてworkflowが人気の話題になっている理由は、多くの他のエンジニアたちが、まさにこれと同じパターンを使ってworkflowを実装し、大きな成功を収めてきたからである。これらの異なるworkflowを紹介しているのは、同じパターンを自分自身のプロジェクトで使い、それらが他のエンジニアにとってうまく機能してきたのと同様に、自分のプロジェクトでも成功を見出せるようにするためである。

Lesson: Parallelization workflows（parallelizationワークフロー）

別のworkflowを見ていく。アプリケーションを少し変更する。引き続きユーザーには部品の画像をドラッグ&ドロップしてもらうが、今回はユーザーに分析結果、つまり様々な基準に応じて、その部品を作るのに最適な材料を伝えるレポートを返す。

素朴なアプローチとその問題点

この機能を実装するには、ユーザーが提供した画像を短いプロンプトと共にClaudeに送り、そのプロンプトの中で、この部品を金属・ポリマー・セラミックなどのどれで作るのが最良かを判断するよう依頼する、という方法が考えられる。これはおそらく動作するが、この非常にシンプルなプロンプトでClaudeに多くのことを求めすぎている。例えば、材料を選ぶ際に考慮すべき本当の判断基準をClaudeに何も伝えていない。動作はするかもしれないが、最良の結果は得られないかもしれない。

自然な改善策は、このプロンプトに戻ってより多くの詳細を追加することだろう。金属やポリマーなどを推奨すべき様々なシナリオをClaudeに伝える。金属を使うべき基準、ポリマーを使うべき基準、セラミック・コンポジット・最後に木材などについての基準を与えていくと、結果として非常に巨大なプロンプトになる。Claudeは1つのステップの中で多くの分析と多くの作業をこなさなければならず、Claudeを混乱させかねない。これでは最良の結果につながらない可能性がある。

改善策: 並列にリクエストを分割する

より良いアプローチとして、ユーザーが画像を最初に送信したときに、並列で複数の異なるリクエストをClaudeに送るという方法がある。個々のリクエストにはそれぞれ専用のプロンプトを含め、この部品を金属・ポリマー・セラミック・コンポジットなどのどれで作るのが良いかをClaudeに尋ねる。つまり、それぞれ別々のリクエストの中で、Claudeに1つの材料についての適合性を尋ねているということである。

このアプローチでは、個々のプロンプトを特定の材料に特化させることができる。Claudeはもはやすべての材料を同時に気にする必要がなく、一度に1つの材料だけに集中できる。

Claudeから応答が返ってきたら、それぞれの分析結果——金属・ポリマー・セラミック・コンポジットなどでこの部品を作る適合性——を取得できる。これらの分析結果をすべて取得したら、フォローアップリクエストの中で再びClaudeに渡し、それぞれの分析結果を検討した上で最終的にどの材料を使うべきかを判断するよう依頼する。ここでもClaudeは事前にすべての材料を比較検討する必要はなく、最も有望に見える分析結果だけを見ればよい。

parallelization workflowの定義

これは parallelization workflow の一例である。parallelization workflowの考え方は、1つのタスクを複数の異なるサブタスクに分割するというものである。これらのサブタスクはそれぞれ並列に、つまり同時に実行できる。そして、これらすべての異なるサブタスクからの結果を取得し、最終的なaggregator（アグリゲーター）ステップの中で結合する。今回の例では、アグリゲーターはClaudeによるこの最終ステップだった。各並列タスクの結果をアグリゲーターに渡し、Claudeがこの最終的な推奨を出してくれた。

このworkflowの3つの利点:

  1. Claudeが一度に1つのタスクに集中できる。先ほど述べた通り、部品の元画像を多くの異なる材料タイプの基準を列挙した非常に大きなプロンプトと一緒にClaudeに渡すと、Claudeはすべての材料の長所と短所を同時に検討しようとして少し混乱したり気が散ったりする可能性がある。
  2. 各サブタスクで使われているプロンプトを非常に簡単に改善・評価できる。
  3. このフローは一般によくスケールする。他のサブタスクの実行を損なうことなく、いつでも追加のサブタスクを追加できる。

Lesson: Chaining workflows（chainingワークフロー）

次に見ていくworkflowは少し当たり前で単純に見えるかもしれないが、実は特定の状況——非常によく遭遇することになる状況——において、最も有用なworkflowの一つになる。

ソーシャルメディア動画マーケティングツールの例

アプリケーションをまた少し変更する。ソーシャルメディアマーケティングツールを構築していると想像する。ユーザーは自分のソーシャルメディアアカウントの話題（トピック）を入力するよう求められる——アカウントが主にどんな内容にフォーカスしているか、といったものである。このアプリケーションの目標は、動画を生成してそのアカウントに投稿することである。

実装イメージ: 大量のツールを備えた高度なagentは特に必要ない。事前に定義されたステップを一つずつ順番にたどっていくworkflowを組み立てればよい。

  1. ユーザーがフォームに入力したトピックを使って、Twitterでトレンドのトピックを検索する。
  2. トピックのリストをすべてClaudeに渡し、最も興味深いトピックを選ぶよう依頼する。
  3. そのトピックについてWebリサーチを行うよう、Claudeへのフォローアップリクエストを行う。
  4. リサーチが完了したら、ショート動画向けのスクリプトを書くようClaudeに依頼する。
  5. スクリプトができたら、AIアバターとテキスト読み上げ（text-to-speech）プログラムを使って実際の動画を作成する。
  6. 最後にその動画をソーシャルメディアに投稿する。

これは chaining workflow の一例である。chaining workflowでは、1つの大きなタスク（今回の場合は動画を生成してソーシャルメディアに投稿すること）を取り、それを一連の明確なステップに分割する。今回の場合、サブタスクはClaudeに送った個々の呼び出しだった。これら3つのタスクすべてを単一のClaude呼び出しの中でまとめて達成しようとすることもできた——トピックのリストをClaudeに渡し、最も興味深いトピックを選ばせ、そのトピックをリサーチさせ、単一のプロンプトの中でスクリプトを書かせる、という具合に。しかし、これを3つの別々の呼び出しに分割することで、Claudeが一度に1つのタスクだけに集中できるようにしている。

chaining workflowが本当に重要になる理由: 長いプロンプトでの制約遵守問題

このworkflow自体は単純で当たり前に思えるかもしれず、すでに過去に実装したことがあるようなものかもしれない。しかし講師がこのworkflowを特に取り上げる理由は、Claudeを使って大きなプロンプトから一貫して質の高い出力を得るために理解すべき、最も重要なworkflowの一つになるからである。

まだ遭遇したことがなくても、いつか必ず遭遇するであろうシナリオを紹介する。あるトピックについての記事を書くためにClaudeを使っているとする。最初は非常にシンプルなプロンプトをClaudeに送り、記事を書くよう依頼するかもしれない。結果は返ってくるが、まずまずではあっても気に入らない部分があるかもしれない。

時間をかけてプロンプトを発展させていくうちに、「これは絶対にやらないで」というやってほしくないことの長いリストを作ることになるかもしれない。しかし、どれだけこれらの項目を繰り返し伝えても、Claudeはなぜか常に絵文字を使い、AIによって書かれたことに言及し、全体的に安っぽく（cringey）非プロフェッショナルなトーンになってしまう応答を返してくることがある。このような制約を何度繰り返しても、Claudeがこのような記事を書き続けてしまうことがある。

解決策: シンプルなprompt-chaining workflow

  1. すべての制約を含んだ最初の長いプロンプトを送り、求めているものに完全には合致しない最初の記事を受け取ることをいったん受け入れる。Claudeは書き出した制約の一部を必然的に破ってしまうかもしれない。
  2. その問題を修正するため、Claudeが今書いたばかりの記事を渡してフォローアップリクエストを行う。記事の下に、特定の方法で記事を書き直すようClaudeに依頼する。例えば「著者がAIであると識別している箇所を見つけてその言及を削除する」「すべての絵文字を見つけて削除する」「プロのテクニカルライターが書くようなスタイルでテキストを書く」といった指示を与える。

このchaining workflowを使い、タスクを複数のステップに分割することで、Claudeは提示された個々のタスクにずっと集中しやすくなる。最初の長いプロンプトに詰め込んだすべての要件を必ずしも満たせなかったとしても、フォローアッププロンプトによってClaudeは本当に気にしている制約だけに集中できるようになり、望んでいたスタイルで記事を書き直してくれることが期待できる。

まとめ: prompt chainingは一見単純で当たり前のことに思えるかもしれないが、多くの制約を伴うタスクをClaudeに与え、Claudeが期待するほどそれらの制約に常に従ってくれるわけではないという場面に遭遇するたびに、頻繁に使うことになる手法である。

Lesson: Routing workflows（routingワークフロー）

次のworkflowは、先ほどのソーシャルメディアマーケティングツールを改善する一つの方法を示す。再び、ユーザーがトピックを入力し、何らかの方法で動画を生成し、ユーザーのソーシャルメディアアカウントに投稿する、という想定である。

問題: トピックによってスクリプトのトーンが大きく異なるべき

考えてほしいのは、スクリプト生成プロセス——つまり、これらの異なる動画で使われる実際のトーンや言葉遣い——についてである。例えば「プログラミング」というトピックと「サーフィン」というトピックという、2つの異なるトピックが与えられたとき、性質がまったく異なる動画スクリプトを期待するはずである。

解決策: routing workflow

与えられたトピックが、そのトピックの性質にうまく合った動画スクリプトを生成できるようにするworkflowを紹介する。

  1. まず、ユーザーが作成を依頼してきそうな動画のあらゆる可能なジャンルについて考える。例えば、トピックが当てはまりうるジャンルとして「エンターテインメント」「教育」「コメディ」など6つの異なるジャンルを決めるとする。先ほどの例で言えば、プログラミングは教育、サーフィンはエンターテインメントに当てはまるだろう。
  2. これらの異なるジャンルそれぞれについて、スクリプト生成用のプロンプトを書く。教育的な性質のトピックだと分類された場合は、興味深い例や興味深い問いかけなどを含む、明確で魅力的なスクリプトを書くようClaudeに依頼するプロンプトを使う。ユーザーがサーフィンというトピックを与えてきた場合はエンターテインメントに分類し、トレンド感のある言葉遣いや魅力的なフック（引き込み）などを持つサーフィンについてのスクリプトを書くようClaudeに依頼するプロンプトを使う。

実際のフロー:

  1. ユーザーが入力したトピック（例: 「Python functions」）だけを含むリクエストを最初にClaudeに送り、そのトピックをあらかじめ用意したカテゴリのいずれかに分類するよう依頼する。この例では、「Python functions」は最も近いカテゴリとして「教育」に分類されるだろう。
  2. Claudeからのこの応答を受け取り、フォローアップリクエストを行う。Python関数について、明確で魅力的な情報と、考えさせられるような例を持つスクリプトを書くようClaudeに依頼する。
  3. そのようにして、教育的な動画にふさわしいトーンと質を持ったスクリプトが返ってくることが期待される。

これは routing workflow の一例である。routing workflowでは、ユーザーの元の入力を取り、それをrouting stepに渡す。このrouting stepはおそらくClaudeへの呼び出しそのものであり、ユーザーの入力やタスクを何らかの方法で分類するようClaudeに依頼する。そして、Claudeの回答に応じて、ユーザーの入力を特定のフォローアップ処理パイプラインへと転送する——複数ある候補のうちの一つだけに、という具合である。これらの異なるルーティング先の選択肢は、それぞれ異なるworkflowや、カスタマイズされたプロンプト、あるいはユーザーが求めるタスクの処理に特化したカスタマイズされたツールのセットを内部に持つことができる。

Lesson: Agents and tools（agentとtool）

これまで複数のworkflowを見てきたので、ここからは方向転換してagentについて議論を始める。agentを理解する最も簡単な方法は、workflowを思い出すことである。特に、workflowを実際に使う場面を思い出すとよい。

agentを取り巻くこの柔軟性こそが、agentを構築する上で非常に魅力的な点である。考え方としては、agentを作り、それが十分にうまく機能することを確認すれば、そのagentは幅広い異なるタスクを解決できる、というものである。ただし、このアプローチには大きな欠点もある（これは後ほど議論する）。

ツールを組み合わせる能力

agentの重要な側面の一つは、異なる組み合わせでツールを利用する能力である。これを理解するために、コースの前半で取り組んだ例——Get Current Date Time、Add duration to Date Time、Set Reminderという3つのツールを組み合わせた例——を思い出してほしい。これらのツールはそれぞれかなりシンプルなものだったが、Claudeはこれらを異なる、時に意外な方法で組み合わせて、事前には計画していなかったような幅広いタスクを達成できた。いくつか例を挙げる:

これらはすべて、Claudeが一連のツールを取り、興味深い方法で組み合わせて特定のタスクを解決できる例である。ここから、agentに関する最初の大きな教訓が導かれる。

教訓: agentに与えるツールセットは「合理的に抽象的」であるべき

agentに提供するツールのセットは、合理的に抽象的（reasonably abstract）である必要がある。これを理解するのに最適な例が、Claude Codeとそこに提供されている具体的なツールである。

Claude Codeは非常に小さな抽象的なツールセットにアクセスできる。ここで言う「抽象的」とは、汎用的・一般的、あるいは目的として多少あいまい、という意味であり、何か一つの用途にハイパー特化しているわけではない。Claude Codeが持つツールの例:

Claude Codeは、こうした異なるツールを組み合わせることで、既存のコードベースを驚くべき方法で修正し、機能を追加できる。逆に、Claude Codeは、1つの非常に具体的なタスクを1つの具体的なシナリオでのみ果たすような、ハイパー特化したツールにはアクセスできない。Claude Codeに明確に存在しないツールの例:

得られる教訓: agentを作るときは常に、Claudeが何らかの方法で組み合わせて目標を達成できるような、合理的に抽象的なツールを提供することを心がけるべきである。

具体例: ソーシャルメディア動画作成agent

先ほどのソーシャルメディア動画作成agentの例に戻ると、4つの異なるツールを提供することが考えられる:

  1. Bash: FFmpegへのアクセスを与える。FFmpegは、画像・動画・テキスト・音声などの入力から動画を生成するためによく使われるCLIツールである。
  2. Generate imageツール
  3. Text to speechツール: 動画生成プロセスを補強するため。
  4. Post mediaツール: 生成されたコンテンツをソーシャルメディアアカウントに投稿するため。

Claudeはこのツールセットを、かなり予想外の方法で使いこなすことができる。例えば:

Lesson: Environment inspection（環境の検査）

agentに関して次に議論する考え方は、environment inspection（環境の検査）である。

前にcomputer useを見たときのことを思い出してほしい。何かアクション（タイピングやマウスの移動など）が左側のログに記録されるたびに、その直後にスクリーンショットが現れていたはずである。Claudeが何らかのテキストを入力しようとし、それが最初のパネルにログとして記録され、その直後にスクリーンショットが現れる、というものである。

これをClaudeの視点から見てほしい。Claudeが何かをタイプしたりクリックしたりすると、おそらくページが変化するはずだが、Claudeにはそれがどう変化したのか本当には分からない。ボタンをクリックすると新しいページに遷移するかもしれないし、メニューが開くだけかもしれない。取った行動の結果を理解するために、Claudeは新しい状態、つまり自分が置かれている環境を理解するためのスクリーンショットを必要としていた。

この考え方は、組み立てるあらゆるagentに当てはまる: 行動を取った後（そして時には行動を取る前にも）、Claudeは単にツールが返す値を超えて、その行動の結果を評価する何らかの方法を本当に必要としている。自分の環境を理解できるようClaudeを助けることで、Claudeはタスク完了に向けた進捗をより良く判断でき、予期しない結果やエラーにもより良く対処できるようになる。

Claude Codeでの同様の例

Claude Codeを使うときにも、非常によく似た考え方が見られる。ある例では、講師が main.py ファイルを更新するようClaudeに依頼している。ここで与えたタスク（追加のルートを1つ加えるだけ)は非常にシンプルなものである。しかし、このファイルを何らかの形で修正する前に——これは当たり前に思えるだろうが——Claudeはまずファイルの現在のコードが何であるかを理解する必要がある。つまり、Claudeはファイルの内容を読む何らかの方法を必要としている。当たり前に思えるかもしれないが、自分でagentを構築する際には、書き込む前に読むというこの考え方を常に意識することが推奨される。

ソーシャルメディア動画agentへの適用

この考え方は、先ほどのソーシャルメディア動画agentにも当てはまる。Claudeへのリクエストを行うとき、「Pythonについての動画を作成してソーシャルメディアアカウントに投稿して」というようなタスクとツールのリストを与えるだけでなく、動画を生成した後どのように環境を検査できるかをClaudeに理解させる特別な指示を、システムプロンプトの中に含めることが考えられる。

個人的には、FFmpegを使って動画を生成する作業をClaudeに任せる場合、テキスト読み上げ機能を使って生成した音声クリップのセリフの配置（音声クリップがいつ再生されるか）について、時々ミスをすることが予想される、と講師は述べる。タスク完了に向けた進捗をClaudeがより良く理解できるよう助けるため、以下のような指示を与えることが考えられる:

これにより、Claudeは自分の行動の結果——実際に作成した動画——を検査し、タスクを本来あるべき通りに完了しているかを確認できるようになる。

Lesson: Workflows vs agents（workflowとagentの比較）

workflowとagentの様々な側面を比較・対照してまとめる。

workflow

agent

結論: 基本はworkflow、agentは本当に必要なときだけ

agentは確かに興味深いものだが、エンジニアとしての第一の目標は信頼性を持って問題を解決することである。ユーザーは、こちらが作った凝ったagentのことなど気にしていない。ユーザーが本当に求めているのは、100%の確率で動作する製品である。この点を踏まえると、一般的な推奨は、可能な限りworkflowの実装に焦点を当て、本当に必要な場合にのみagentに頼る、というものである。

Lesson: Course Wrap Up（コースのまとめ）

このコースを最後までやり遂げたなら、それは相当な努力を注いだ証であり、講師から祝福が述べられる。締めくくる前に、扱った主要トピックを簡単に振り返り、今後研究すべき推奨フォローアップトピックが紹介される。

コースの振り返り

今後の推奨フォローアップトピック

時間の制約上、このコース内ではすべてのトピックをカバーすることはできなかった。今後自分で調べることが推奨される主要なトピック:

以上でコースは終了する。講師はこのコンテンツを楽しんでもらえたこと、そしてこの内容に取り組む時間を割いてくれたことへの感謝を述べて締めくくる。

章末まとめ

Claude 学習サイト — 完全ローカル静的サイト（build.py で生成）。進捗はこのブラウザの localStorage に保存されます。