# Alejandro Rioja — JA > Alejandro Rioja — AI agent systems for founders. Plus posts on growth, marketing, sales, ops, and business from inside live P&Ls. Site: https://alejandrorioja.com/ja/ Author: Alejandro Rioja Language: ja --- ## Claude Fable 5 ファーストインプレッション:あるオペレーターの視点 Source: https://alejandrorioja.com/ja/claude-fable-5-first-impressions/ Published: 2026-06-12 Updated: 2026-06-12 Tags: AI Agents TL;DR: Fable 5 は Anthropic で最も高性能なモデルであり、難しく長期にわたるエージェント作業でその実力が現れる——だが、デフォルトでアップグレードすべき対象ではない。トークン単価は高く、トークン数を約30%膨らませる新しいトークナイザーを使い、無効化できない常時オンの thinking を実行し、分類器レベルでリクエストを拒否することがある。ほとんどのワークロードでは Opus 4.8 が依然として正しい選択だ。タスクが本当に難しいときにこそ Fable 5 を手に取ろう。 ## 目次 _2026年6月更新。_ **TL;DR:** Fable 5 は Anthropic で最も高性能なモデルであり、難しく長期にわたるエージェント作業でその実力が現れる——だが、デフォルトでアップグレードすべき対象ではない。トークン単価は高く、トークン数を約30%膨らませる新しいトークナイザーを使い、無効化できない常時オンの thinking を実行し、分類器レベルでリクエストを拒否することがある。ほとんどのワークロードでは Opus 4.8 が依然として正しい選択だ。タスクが本当に難しいときにこそ Fable 5 を手に取ろう。 **【オペレーターの視点】** 私はコンサルティングブランドとピックルボール施設にまたがって30以上の本番エージェントを運用している。だから新しいフラッグシップモデルは、私にとってベンチマークではない——それは費用項目であり、移行作業だ。実際にそのうちのいくつかに Fable 5 を組み込んだときに何が変わったか、そしてどこには Opus 4.8 を残したかを以下にまとめる。 ## Fable 5 とは実際のところ何なのか [Claude](/recommends/claude) Fable 5 は、Anthropic が広く提供してきた中で最も高性能なモデルだ。狙いはスペクトルの要求が厳しい側にある——深い推論と長期にわたるエージェント作業、つまりエージェントが何十回ものツール呼び出しをまたいで筋道を見失わずに計画を保持しなければならない実行だ。 API サーフェスは Opus 4.7/4.8 とほぼ同一で、おかげでテストは容易だった。デフォルトで100万トークンのコンテキストウィンドウ、リクエストあたり最大128Kの出力トークン。最近の Opus 系で何かを作ったことがあるなら、リクエストの形は見慣れたものだ。違いは細部にあり、そしてその細部にこそ金と驚きが潜んでいる。 混乱しないように命名についてひとつ注記しておく。**Mythos 5** は同じモデルだ——同じ能力、同じ価格、同じ挙動で、Anthropic の Project Glasswing プログラムを通じてのみ利用できる。そのプログラムに入っていないなら、あなたが欲しいモデルは `claude-fable-5` だ。以下の内容は両方に当てはまる。 ## 本当に優れている点 私はまず最も難しいエージェントタスクを投げてみた。大量のソースを読み込み、主張を相互チェックし、出典付きのブリーフを書く、複数ステップのリサーチ&統合の実行だ。これは弱いモデルが漂流するたぐいの仕事だ——10回ほどツールを呼び出したあたりで、どの主張がどのソース由来だったかを見失う。 Fable 5 は筋道を保った。統合はより引き締まり、引用は正しい主張に結びついたままで、私の Opus 4.8 版がこっそり平均化して見過ごしていたソース間の矛盾を2つ捉えた。長く構造化された推論では、これは本物の一段の進歩だ——わずかなベンチマーク上昇ではない。 これがその正直な評価だ。あなたのエージェントの失敗モードが「難しい10%で崩れる」ものなら、Fable 5 はそのギャップを縮める。あなたのエージェントがニュースレターを要約したりソーシャル投稿を下書きしたりしているなら、違いは感じられないだろう——そして使っていない能力に対して支払うことになる。 ## 誰も警告してくれないコストの落とし穴 リリースノートを流し読みすると痛い目に遭うのがこれだ。Fable 5 には**新しいトークナイザー**が搭載されており、同じ内容が Opus 系よりおよそ**30%多いトークン**にトークナイズされる。 これは価格と複合するので、もう一度読んでほしい。Fable 5 はそもそも Opus ティアより高い価格設定だ(入力100万トークンあたり10ドル、出力100万トークンあたり50ドル)。そこへ、すべてのプロンプトとコンプリーションに約30%のトークン膨張を上乗せする。変更のないワークロード——同じプロンプト、同じ出力——でも、エージェントの動作を何ひとつ変える前に、移行後は意味のあるレベルでコストが増えうる。 だから古い数字を使い回してはいけない。あなたの `max_tokens` 設定、コンテキストウィンドウの予算、実行あたりのコスト見積もり——それらはすべて別のトークナイザーで測定されたものだ。朗報もある。`model: "claude-fable-5"` を渡すと、トークンカウントのエンドポイントは**両方**のトークナイザーでのカウントを返してくれる。だから何かを切り替える前に、実際のプロンプトで差分を測定できる。 ```bash # Measure the tokenizer delta on YOUR prompt before migrating. # The response includes input_tokens (new) AND input_tokens_prior_tokenizer (old). curl https://api.anthropic.com/v1/messages/count_tokens \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-fable-5", "messages": [{"role":"user","content":""}] }' ``` 私はこれを最も重いプロンプトから順に実行した。差分は一様ではなかった——内容によって変わる——が、「約30%多めに見積もり、そこへ価格プレミアムを加える」というのが正しい心構えだった。 ## thinking は常時オン——しかも無効化できない Fable 5 では、適応的な thinking が常に動いている。Opus 系に対する唯一の新しい破壊的変更はこれだ。明示的に `thinking: {type: "disabled"}` を送ると、400 が返ってくる。修正は単純で——単に `thinking` パラメータを丸ごと省けばいい——だが、安く速い呼び出しのために thinking を明示的に無効化していたコードがあったなら、そのコードは今やエラーになる。 また、生の思考の連鎖(chain of thought)は返ってこない。Fable 5 はそれを保護している。通常の `thinking` ブロックは受け取れ、`display: "summarized"` で読みやすい要約を求めることもできるが、フィルタリングされていない生の推論が露出することは決してない。ほとんどのアプリにとってこれは問題ではない——可視性が必要なら要約を読めばいい。これが重要になるのは**マルチターンのエージェント**だ。同じモデルで会話を続けるとき、thinking ブロックを**そのまま変更せずに**渡し返さなければならない。落としたり編集したりするとそのターンは壊れる。エージェントループを構築しているなら、thinking ブロックは一字一句そのまま運ぶ不透明なトークンとして扱おう。 ## 拒否はいまや制御フローの問題だ これは、モデルを取り巻くコードの書き方に最も影響する変更だ。Fable 5 は受信リクエストに安全性分類器を走らせ、主に研究目的の生物学とほとんどのサイバーセキュリティ関連の内容を対象にしている。リクエストが拒否されると、`stop_reason: "refusal"` を伴う**正常な HTTP 200** が返ってくる——エラーでも例外でもない。`content` 配列は空かもしれない。 もしあなたのコードが `stop_reason` を先に確認せずに `response.content[0].text` を実行していたら、リクエストが拒否された日にクラッシュする。そして害のない隣接領域の作業——正当なセキュリティツール、ライフサイエンスのタスク——もときに誤検知を引き起こすことがあるので、これは怪しいことをしている人だけの問題ではない。 ルールはこうだ。**`stop_reason` で分岐し、決して `stop_details` で分岐しないこと。** ```typescript const res = await client.messages.create({ model: "claude-fable-5", max_tokens: 1024, messages, }); if (res.stop_reason === "refusal") { // classifiers declined — content is empty or partial. Don't read content[0]. await handleRefusal(res); } else { console.log(res.content[0].text); } ``` 本番向けには、もっときれいな道がある。サーバーサイドの `fallbacks` パラメータ(ベータ)だ。これは拒否されたリクエストを同一のラウンドトリップ内で自動的に `claude-opus-4-8` で再試行し、クレジット方式の再課金が適用される。エージェントを無人で動かしているなら、単一の誤検知による拒否が実行全体を行き止まりにしないように、これを組み込んでおこう。これは私が[本番で失敗し続ける](/blog/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it)エージェントについて何度も学び直している教訓と同じだ。モデルが賢くなっても、エッジケースを処理する必要はなくならない——エッジケースの場所が移るだけだ。 ## さらに2つの移行上の詳細 私の時間を奪った小さな点を、あなたの時間を奪わないようにいくつか挙げておく。 - **アシスタントの prefill は不可。** 最後のアシスタントターンを prefill して出力を誘導していたなら、そのパターンはなくなった。代わりに構造化出力(`output_config.format`)かシステムプロンプトの指示を使おう。 - **30日間のデータ保持が必須。** Fable 5 はゼロデータ保持では利用できない。コンプライアンス上の理由で ZDR を使っているなら、Fable 5 は選択肢から外れ、Opus 4.8 が上限のままになる。これは移行を計画する*前に*確認すること、後ではなく。 ## 実際に乗り換えるべきか? 実際に使い込んだうえでの、私のオペレーターとしての判断はこうだ。**Fable 5 は「最新モデルへのアップグレード」のデフォルトの対象ではない——Opus 4.8 がそれだ。** これは人を驚かせるが、正しい枠組みだ。Opus 4.8 は 4.7 からのモデルIDの差し替えで、新しい破壊的変更はなく、より安く、圧倒的多数のエージェント作業では出力品質において見分けがつかない。 Fable 5 が真価を発揮するのは、本当に難しいタスクだ。多くのステップをまたいで一貫性を保たなければならない長期エージェント、複数ソースにわたる深い推論、消し去ろうとしている失敗が微妙であるような実行。そうしたものに対しては、能力は本物でありプレミアムに見合う。それ以外のすべて——コンテンツの下書き、分類、ルーティング、要約——では、知覚できない品質のために、より多くのトークンをより高い価格で支払っていることになる。 結局、私は両方を運用することにした。リサーチ&統合エージェントは Fable 5 へ移した。それ以外はすべて Opus 4.8 に残した。この使い分けこそが要点のすべてだ——流行ではなく、仕事ごとにモデルを選ぶこと。エージェントの艦隊を運用しているなら、私が[2026年のオペレータースタック](/blog/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack)について書いたのと同じ規律が当てはまる——難しい仕事は高価なモデルにルーティングし、簡単な仕事に払いすぎるのをやめよう。 ## オペレーターとしての結論 他に何かに手をつける前に、あなたの一番難しいタスクで Fable 5 をテストしよう——それが報われる場所であり、そこで針が動かないなら、どこでも動かない。実際のプロンプトに対してトークンカウンターを走らせ、約30%のトークナイザー膨張と価格プレミアムが請求書で不意打ちにならないようにしよう。Fable 5 が本番に触れるところには必ず `stop_reason: "refusal"` のチェック(またはサーバーサイドの Opus 4.8 へのフォールバック)を加えよう。そして意図的にルーティングする——難しい10%には Fable 5、残りには Opus 4.8。最良のモデルとは最も高性能なものではない——仕事に合ったものだ。 --- ## AIエージェント入門・完全ガイド:Cowork、Codex、そして本当に仕事をこなすツール Source: https://alejandrorioja.com/ja/ai-agents-for-beginners-cowork-codex-guide/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: AIエージェントはチャットボットの一歩先です。普通の言葉で目標を伝えると、エージェントが仕事をこなします——ファイルを読み、下書きを作り、整理し、コードを書いて実行する。Coworkはノーコードの入口、CodexとClaude Codeはコードベースに関わる人向けです。重要なスキルは、プログラミングを覚えることではなく、明確でスコープの絞られた指示を書くことです。 ## Table of contents _2026年6月更新。_ **TL;DR:** AIエージェントはチャットボットの一歩先です。普通の言葉で目標を伝えると、エージェントが仕事をこなします——ファイルを読み、下書きを作り、整理し、コードを書いて実行し、自分の出力を確認する。**Cowork**は非技術者向けのノーコード入口、**Codex**と**Claude Code**はコードベースに関わる人向けです。唯一重要なスキルは、プログラミングを覚えることではなく、明確でスコープの絞られた指示を書くことです。 **【著者より】** 私は毎日30以上のコード化されたエージェントを運用していますが、ほとんどの人はコードなしで価値の80%を引き出せます。必要なのは明確な指示と、それを実行する場所だけです。このガイドは、コードを一行も書いたことがない賢い友人に渡す入門書として書きました。 ## 「AIエージェント」とは実際何なのか チャットボットは質問に答えます。**エージェント**はタスクを完了します。違いは、エージェントがループの中で行動を取れること——ドキュメントを読み、次にすることを決め、ファイルを書き、コマンドを実行し、結果を確認し、問題を修正する——あなたが一つひとつのステップを指示しなくても、です。 具体的には:「このスプレッドシートをどう整理すればいい?」とは聞きません。「このスプレッドシートを渡します——重複を削除して、日付フォーマットを修正して、メールアドレスが空の行にフラグを立ててください」と言えば、エージェントがやり遂げ、整理済みのファイルを渡してくれます。*アドバイス*から*完成した仕事*への転換——それがすべてです。 ## 二つのツールファミリー この世界への入口は二つあります。自分の仕事に合う方だけ選べばいいです。 ### 第一の扉:ノーコードエージェント(コードを書かない人はここから) **Claude Cowork**は、Claude に目標と材料——ファイル、リンク、メモ——を渡すと、あなたがレビューして使う成果物を生み出すワークスペースです:下書き、要約、計画、整理済みのスプレッドシート。あなたが書くのは指示であって、コードではありません。「プログラミングツール」ではなく、「速く読めて絶対に疲れない、とても優秀なアシスタント」と考えてください。 マーケター、創業者、オペレーター、ライター、アナリスト——仕事が主にドキュメント・リサーチ・意思決定で構成されている人にとって、ここが正しい出発点です。 ### 第二の扉:コーディングエージェント(コードベースが絡んだら使う) **OpenAI Codex**と**Claude Code**は、ソフトウェアが作られる場所——ターミナル、IDE、クラウド——に生きているエージェントです。変更を説明すると(「ダークモードの切り替えを追加して」「この失敗しているテストを修正して」「このファイルを新しいAPIに移行して」)、エージェントがコードを編集し、実行し、動くまで繰り返します。あなたはすべてをレビューする。エージェントはタイピングを担当する。 シニアエンジニアでなくても使えます。多くの非開発者がコーディングエージェントを使って小さなウェブサイトを立ち上げ、スプレッドシートをスクリプトで自動化し、自分が書いていないツールのバグを修正しています。ただし学習曲線は確かにあるので、ほとんどの初心者は第一の扉から始め、本当にコードが必要なタスクに直面したときに第二の扉に進むのがベターです。 ## 最初の成果(今日やる) よくやっている小さくて面倒なタスクを一つ選びましょう。最初の候補として良いもの: - 乱雑な会議の議事録を、クリーンなメモとアクション項目リストに変換する。 - 長いPDFを5つの箇条書きと3つの価値ある質問に要約する。 - 雑な下書きメールを、明快で温かく120字以内になるよう書き直す。 次に、エージェントをヒットアンドミスではなく信頼性の高いものにする型を使います——**役割→入力→正確な指示→制約→チェック**: > あなたは私のアシスタントです。以下に[会議の議事録/PDF/メール下書き]を貼ります。次のことをしてください:[太字の「アクション項目」リスト付きのクリーンなメモに整理する/5つの箇条書き+3つのフォローアップ質問に要約する/明快で温かく120字以内になるよう書き直す]。私の文体を保ってください。始める前に、曖昧な点があれば一つだけ質問してください。 > > [ここにコンテンツを貼り付け] 以上です。あなたはタスクを委任しました。この型がゲームのすべてです——Cowork、ChatGPT、コーディングエージェントのどこで使っても同じように機能します。 ## エージェントを信頼性の高いものにする四部構成のプロンプト 初心者は「魔法のフレーズ」があると思いがちです。そうではありません。秘訣は具体性です。信頼性の高いエージェント指示にはすべて四つの要素があります: 1. **役割**——このタスクにおけるエージェントの立場(「あなたは私のリサーチアシスタントです」)。 2. **コンテキスト**——材料と*なぜ*(「フィンテック創業者との営業電話の準備をしています」)。 3. **タスク**——正確でスコープの絞られたアクション(「最近の資金調達ラウンドに関する事実を3つ見つけ、冒頭の質問を2つ下書きしてください」)。 4. **制約+チェック**——フォーマット、長さ、トーン、および推測する前に聞く指示(「箇条書きのみ、ソースを引用、企業名が曖昧なら一つ確認の質問をしてください」)。 曖昧に入れれば曖昧に出ます。エージェントができることが増えるほど、あなたの明確さが重要になります——誤解したチャットボットは一文を無駄にするだけですが、誤解したエージェントは取り消しに午後一つかかる仕事を無駄にします。 ## 初心者が避けるべきミス - **検索エンジンのように扱う。** 一行の質問はしないこと。実際のファイルで実際の仕事を渡しましょう。 - **制約を省く。** 「計画を書いて」では文字の壁が返ってきます。「3つのフェーズとタスクごとの担当者を含む一ページの計画を書いて」なら使えるものが返ります。 - **チェックを求めない。** 「曖昧な点があれば一つだけ質問してください」を加えると、エージェントが動く*前*に誤解を捕まえられます、後ではなく。 - **重要なコードでコーディングエージェントを無人で動かす。** diffをレビューしましょう。エージェントは速くてほぼ正しいですが、「ほぼ」という言葉がその文章では仕事をしています——本番に出るものはすべて人間がループに入ってください。 - **早まって第二の扉に向かう。** タスクがドキュメントと意思決定なら、ターミナルを開く必要は一切ありません。 ## 最初のツールの選び方 - **仕事がドキュメント・リサーチ・ライティング** → **Cowork**から始める(または既に払っているチャット製品をエージェントモードで使う)。 - **ソフトウェアを構築または修正したい** → **Claude Code**または**OpenAI Codex**。 - **定期的・自動的な仕事が欲しい**(日次ダイジェスト、週次レポート)→ プロンプトを手動でマスターしてから**[スケジュールタスク](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/)**に進む。 ## AIエージェント初心者FAQ——2026年版 ### AIエージェントを使うためにプログラミングを知る必要はありますか? いいえ。Claude Coworkのようなノーコードエージェントは非技術ユーザー向けに設計されており、普通の言葉で指示を書きます。CodexやClaude Codeのようなコーディングエージェントは学習曲線がありますが、それでも自分をプログラマーと思っていない人がますます多く使っています。まずノーコードから始め、タスクが必要とするときだけコードに移行しましょう。 ### チャットボットとAIエージェントの違いは何ですか? チャットボットは質問に答え、エージェントはタスクを完了します。エージェントはループの中で一連の行動を取れます——読む、決める、行動する、確認する、修正する——アドバイスではなく完成した仕事を生み出します。実際には同じ製品が両方やることが多く、「エージェントモード」がエージェントの動作です。 ### CoworkはCodexより優れていますか? 違う仕事のためのものなので、優劣はありません。Coworkはドキュメント・リサーチ・オペレーション向けのノーコードワークスペースです。CodexとClaude Codeはソフトウェアの構築と修正のためのコーディングエージェントです。自分のタスクに合う方を選んでください。 ### AIエージェントから良い結果を得るには? 具体性です。四部構成の型を使いましょう:役割、コンテキスト、正確なタスク、制約+チェック。実際の材料を渡し、欲しいフォーマットを伝え、始める前に曖昧な点を報告するよう求めましょう。明確な指示はどんな「魔法のプロンプト」よりも重要です。 ### AIエージェントを自律的に動かしても安全ですか? リスクが低く取り消し可能なタスク(下書き、要約、整理)なら、安全です——出力を確認して進みましょう。実際のシステムを変える何か(コードの出荷、メッセージの送信、データの削除)については、人間をループに入れ、実行前にレビューしてください。取り消しやすさが正しい判断基準です:取り消しが容易なほど、より安全に自律性を持たせられます。 **関連記事:** [ChatGPTの回答で引用される方法](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) · [llms.txtプレイブック](https://alejandrorioja.com/llms-txt-playbook/) · [Claudeスケジュールタスクの使い方](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/) --- **ビジネスでエージェントを活用するサポートが必要ですか?** オペレーターチーム向けにAIエージェントシステムを構築しています——[お問い合わせ](https://alejandrorioja.com/contact/)、またはこのテーマへの[私の考え方](https://alejandrorioja.com/seo-tips/)をお読みください。 --- ## Anthropicはどうやって収益を得ているのか?Claudeのビジネスモデルを解説 Source: https://alejandrorioja.com/ja/how-does-anthropic-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: Anthropicは5つの主要チャネルを通じてClaude AIモデルへのアクセスを販売しています:従量課金API(トークン単位で課金)、コンシューマー向けサブスクリプション(Claude ProとMax)、エンタープライズプラン(TeamとEnterpriseのシート)、開発者向けClaude Code、Amazon BedrockやGoogle Vertexなどのクラウドマーケットプレイスを通じた流通。コンシューマー向けアプリではなく、APIとエンタープライズ事業が収益の主要ドライバーです。 ## Table of contents _2026年6月更新。_ **TL;DR:** Anthropicは5つの主要チャネルを通じてClaude AIモデルへのアクセスを販売しています:**従量課金API**(トークン単位で課金)、**コンシューマー向けサブスクリプション**(Claude ProとMax)、**エンタープライズプラン**(TeamとEnterpriseのシート)、開発者向け**Claude Code**、Amazon BedrockやGoogle Vertex AIなどの**クラウドマーケットプレイスを通じた流通**。コンシューマー向けチャットアプリではなく、APIとエンタープライズ事業が収益の主要ドライバーです。 **「オペレーターの視点」** 私はAnthropicのAPIを使って毎日開発しているので、メーターの内側からビジネスを見ています。理解すべきポイントは、Anthropicはコンシューマー向けの玄関口を持つB2B企業だということです。あなたが使っているチャットアプリはマーケティングであり収益の一ラインでもありますが、本当のお金は、APIを通じてトークンを消費し、スケールでシート費用を支払う開発者と企業にあります。 ## Anthropicとは何か Anthropicは2021年に設立されたAIセーフティと研究の会社で、大規模言語モデルの**Claude**ファミリーを開発しています。これらのモデルとその周辺ツールを、コンシューマー、開発者、企業に販売しています。AmazonとGoogleを含む戦略的投資家から多額の支援を受けている非公開企業であり、両社はクラウドおよび流通パートナーとしても機能しています。 製品はサービスとしてのインテリジェンスです:ソフトウェアをボックスで購入するのではなく、あなたの代わりに読み、書き、推論し、行動するモデルへのアクセスを借りるのです。以下の各チャネルは、同じコアアセットに対する異なるラッパーです。 ## Anthropicはどうやって収益を得ているのか? ### 1. API(従量課金、コアエンジン) ビジネスの基盤です。開発者と企業はAPIを通じてClaudeを呼び出し、**トークン単位**で支払います——大まかに言えば、入力と出力のテキストのチャンクごとに課金されます。価格はモデルの能力に応じてスケールします: - **Claude Opus**(最も高性能なティア)が最も高価格——入力トークン100万件あたり数ドル程度、出力はその数倍。 - **Claude Sonnet**(バランス型のメインモデル)は中間。 - **Claude Haiku**(高速・低コストティア)が最安値で、大量の単純タスク向け。 出力トークンは入力トークンより高く、長いコンテキスト、プロンプトキャッシング、バッチ処理などの機能には独自の価格設定があります。重要なダイナミクス:**収益は使用量に直接比例してスケールします**。Claudeを自社製品に組み込み、何百万ものユーザーに成長したスタートアップは、Anthropicが新しい契約を結ぶことなく毎月より多くのAPI収益を生み出します。この従量課金モデルこそ、AIラボが「ランレート収益」がこれほど速く成長していると語る理由です——顧客自身の成長と複利で積み重なるのです。 ### 2. コンシューマー向けサブスクリプション(Claude ProとMax) Claudeのアプリ(ウェブ、デスクトップ、モバイル)は無料でお試しいただけますが、ヘビーユーザー向けに有料ティアがあります: - **Claude Pro** ——より高い使用量制限、最良モデルへのアクセス、より大きなコンテキストや優先アクセスなどの機能のための月額固定料金。 - **Claude Max** ——Proの制限に達するパワーユーザー向けの高価格ティアで、使用量の余裕が大幅に増加します。 これはAnthropicの中で最も目に見える部分ですが、顧客の大半が他のビジネスである会社にとって、APIとエンタープライズラインよりは小さなシェアです。その戦略的価値は、収益源としてと同様に、ファネルとブランドサーフェスとしての役割にあります。 ### 3. エンタープライズ(TeamとEnterpriseのシート) 持続的な収益の多くはここにあります。企業は**シート単位**でClaudeを従業員向けに購入し、組織向けに構築されたプランを利用します: - **Team** ——小規模企業向け:プール型使用量、集中課金、コラボレーション機能。 - **Enterprise** ——大規模組織向け:より高いセキュリティとコンプライアンス、シングルサインオン、より大きなコンテキストウィンドウ、管理者コントロール、使用量の保証。 エンタープライズ契約は継続的で、時間とともに拡大し(より多くのシート、より多くの使用量)、収益を安定させるスイッチングコストを伴います。これはモデルの上に重ねられた古典的なSaaSの動きです。 ### 4. Claude Code(開発者ツール) **Claude Code**はAnthropicのエージェント型コーディングツールで——ターミナル、IDE、またはクラウドでコードを書き、編集し、実行するエージェントです。同じサブスクリプションと使用量のレールを通じて収益化されています(Pro/Max/Team/Enterpriseティアに含まれ、プランに対してカウントされます)。戦略的には2つの役割を果たします:それ自体が独立した収益ラインであり、コーディングエージェントは大量のモデルキャパシティを消費するため、高価値のトークン使用量を大量に生み出します。 ### 5. クラウドマーケットプレイス流通(AWS、Googleなど) AnthropicはClaudeを直接販売するだけでなく、主要なクラウドプラットフォームを通じても流通しています: - **Amazon Bedrock**と**Claude Platform on AWS** ——すでにAWSを使用している顧客がAmazonのインフラと課金を通じてClaudeにアクセスします。 - **Google Vertex AI**と**Microsoft Foundry** ——Google CloudとMicrosoftのプラットフォームで同じコンセプト。 これらのチャネルは、企業のクラウド支出と調達がすでに存在する場所で企業に会うことで、Claudeを採用するための摩擦を低減します。収益はプラットフォームと共有されますが、リーチは巨大です——そしてAmazonとGoogleからの深い投資は、これらのパートナーシップを単に商業的なものではなく、戦略的なものにしています。 ### 6. 新興のエージェントプラットフォーム Anthropicはますます、単なる生のモデル呼び出しだけでなく、**エージェントインフラ**——Anthropicがエージェントループを実行し、エージェントがタスクを実行する環境をホストするマネージドサービス——を販売しています。より多くの顧客が「モデルに質問する」から「エージェントに仕事をさせる」へと移行するにつれ、この上位レイヤーはトークン単位のコアに加えて価値を獲得する新しい場所となります。 ## Anthropicは収益性があるのか? Anthropicは非公開企業であり、監査済みの財務諸表を公開していませんが、公開されている状況は同業他社と同じです:**収益は非常に急速に成長している**一方で、同社はコンピューティング(モデルのトレーニングとサービング)と研究人材に莫大な金額を費やしています。他のフロンティアAIラボと同様に、現在の利益ではなくトップラインの成長が見出しになる重投資フェーズにあります。投資家が行っている賭けは、AIがより多くのソフトウェアに組み込まれるにつれて従量課金収益が複利的に成長し、最終的にコンピューティングコストを上回るというものです。 ## OpenAIとの比較 形は似ています——両社ともコンシューマーサブスクリプション、従量課金API、エンタープライズシート、開発者ツールを通じて収益化しています。違いは重点とパートナーシップにあります:Anthropicは開発者/エンタープライズAPIに大きく傾いており、AmazonとGoogleが支援しています;OpenAIはより大きなコンシューマー基盤を持ち、Microsoftとの深いパートナーシップがあります。比較の反対側を見たい場合は、[OpenAIがどのように収益を得ているか](https://alejandrorioja.com/how-does-openai-make-money/)をご覧ください。 ## Anthropicの収益モデル——2026年FAQ ### Anthropicの主な収益源は何ですか? **従量課金API**と**エンタープライズ契約**が最大のドライバーです。開発者と企業はClaudeを呼び出すためにトークン単位で支払い、組織はチーム向けにシート単位のプランを購入します。コンシューマー向けClaudeサブスクリプションは最も目に見える製品ですが、ビジネスラインに比べると収益の小さなシェアです。 ### Claude APIの価格設定はどのように機能しますか? トークン単位で支払います——入力と出力はテキストのチャンクで計測されます。より高性能なモデル(Opus)はバランス型(Sonnet)や高速型(Haiku)モデルよりもトークンあたりのコストが高く、出力トークンは入力トークンよりも高くなります。長いコンテキスト、プロンプトキャッシング、バッチ処理などの機能には独自の価格設定があります。収益は顧客がモデルをどれだけ使用するかに直接比例してスケールします。 ### Anthropicは上場していますか? いいえ。AnthropicはAmazonとGoogleを含む戦略的および ベンチャー投資家に支援された非公開企業です。株式は公開証券取引所では取得できず、確認されたIPOもありません。 ### Anthropicは無料のClaudeアプリで収益を得ていますか? 無料ユーザーからは直接得られません——無料ティアはファネルです。無料ユーザーが**Pro**または**Max**にアップグレードしたとき、チームが**エンタープライズシート**を購入したとき、特に開発者が**API**上でビルドしたときに収益が入ります。無料アプリの役割はリーチとブランドであり;有料ティアとAPIがコンバージョンが起こる場所です。 ### Anthropicの最大の顧客は誰ですか? 主に他のビジネスです:APIを通じて自社製品にClaudeを組み込むソフトウェア企業と、従業員向けにClaudeを展開する企業です。AWS、Google、Microsoft経由のクラウドマーケットプレイス流通も、既存のクラウドプロバイダーを通じて購入する大企業顧客を引き付けています。 **関連記事:**[OpenAIはどのように収益を得ているか](https://alejandrorioja.com/how-does-openai-make-money/) · [AIエージェント入門ガイド](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [ChatGPTの回答で引用される方法](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- ## 短い版 AnthropicはClaudeモデルへのアクセスを貸し出しています。開発者はAPIを通じてトークン単位で支払い、コンシューマーはProとMaxのために毎月支払い、企業はTeamとEnterpriseのためにシート単位で支払い、エンジニアは同じプランでClaude Codeを使用し、クラウドの巨人(AWS、Google、Microsoft)はマーケットプレイスを通じてClaudeを企業に再販売しています。コンシューマー向けの玄関口を持つB2B事業です——そしてメーターこそが、チャットアプリではなく、お金がある場所です。 --- ## OpenAIはどうやって収益を得ているのか?ChatGPTとAPIのビジネスモデル Source: https://alejandrorioja.com/ja/how-does-openai-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: OpenAIの主な収益源は4つ:ChatGPTのサブスクリプション(Plus・Pro・Team・Enterprise・Edu)、開発者がトークン単位で支払う従量課金API、大規模な企業契約、そしてMicrosoftとのパートナーシップ(流通+収益分配契約)。ほとんどのAIラボと異なり、OpenAIの消費者向けサブスクリプション事業が最大の単一収益ラインであり、ChatGPTの規模こそがそのエンジンです。 ## Table of contents _2026年6月更新。_ **TL;DR:** OpenAIの主な収益源は4つあります。**ChatGPTのサブスクリプション**(Plus・Pro・Team・Enterprise・Edu)、開発者がトークン単位で支払う**従量課金API**、大規模な**企業契約**、そして**Microsoftとのパートナーシップ**(流通+収益分配契約)。ほとんどのAIラボと異なり、OpenAIの消費者向けサブスクリプション事業が最大の単一収益ラインであり、ChatGPTの膨大な規模こそがそのエンジンです。 **【オペレーター向け視点】** OpenAIは典型的なエンタープライズAI企業の逆を行っています。まず消費者フェノメノンを作り上げ、その後に開発者・企業向けのビジネスを構築しました。数億人のChatGPTユーザーは、ブランドであると同時に収益エンジンでもあります。この業界の他のプレイヤーは誰もがこのようなトップファンネルを羨んでいます。 ## OpenAIとは何か? OpenAIは**ChatGPT**と**GPT**ファミリーのモデルを生み出したAI研究企業であり、動画モデルSora、画像生成、コーディングエージェントのCodexなどの製品も手がけています。2015年に設立され、2022年末にChatGPTがリリースされると瞬く間に世間の注目を集め、史上最も急成長した消費者向け製品のひとつとなりました。 その構造はユニークです。非営利組織として始まり、フロンティアモデルの訓練に必要な莫大な資金を調達するために利益上限付きの営利部門を設立しました。上場はしておらず、**Microsoft**と深く長期的なパートナーシップを結んでおり、計算リソース・流通・資本の供給を受けています。製品は、他のAIラボと同様に「インテリジェンス・アズ・ア・サービス」——消費者・開発者・企業向けの各チャネルで販売されています。 ## OpenAIはどうやって収益を得ているのか? ### 1. ChatGPTのサブスクリプション(最大の収益ライン) これがOpenAIを競合他社と差別化するポイントです。ChatGPTは無料で使えますが、有料プランが膨大なユーザーベースの一部を継続的な収益へと変換します。 - **ChatGPT Plus** ——最高品質のモデルへのアクセス、より高い利用上限、プレミアム機能を提供する定額月額プラン。大衆市場向けの層。 - **ChatGPT Pro** ——最大限の利用量と最も高性能なモデル設定を求めるパワーユーザー向けの高価格帯プラン。 - **ChatGPT Team** ——共有ワークスペースと管理ツールを備えた、小規模ビジネス向けのシートあたり課金プラン。 - **ChatGPT Enterprise** ——大規模組織向け:高度なセキュリティ、コンプライアンス、SSO、より大きなコンテキスト、利用量の保証。 - **ChatGPT Edu** ——大学・学校向けにカスタマイズされたバージョン。 ChatGPTの週次アクティブユーザーは数億人に上るため、有料プランへの転換率が一桁台の低い数字であっても、巨大なサブスクリプションビジネスが生まれます。この消費者規模こそOpenAIの決定的な優位性であり、サブスクリプションが最大の収益源だと報告されています。 ### 2. API(従量課金、開発者向け) 開発者と企業はOpenAIのモデルを自社製品に組み込み、処理されるテキスト(または画像・音声)のチャンク単位——**トークン**単位で支払います。価格はモデルの能力に応じてスケールし、フラッグシップ推論モデルは小規模・高速・低コストのモデルよりもトークン単価が高く、出力は入力より高めに設定されています。 APIはGPTを基盤に構築するすべての企業を「従量課金顧客」に変え、その請求額は自社の利用量とともに増えていきます。これはすべてのAIラボが依拠する複利的なダイナミクスと同じです。OpenAIを組み込んで数百万ユーザーに成長したスタートアップは、新規契約なしに毎月API収益を増やし続けます。 ### 3. 企業契約 セルフサービスAPIやTeamプランの外で、OpenAIは大企業と大規模なカスタム契約を締結します——大量利用、専用キャパシティ、カスタムサポート、セキュリティとコンプライアンスのコミットメントなどが含まれます。こうした契約は反復的で時間とともに拡大し、企業がモデル上に重要なワークフローを構築すると切り替えが難しくなります。このエンタープライズの動きは消費者ビジネスと並行しており、主要な成長領域です。 ### 4. Microsoftとのパートナーシップ MicrosoftはOpenAIの最大の戦略的パートナーです。この関係はいくつかの軸で機能しています。 - **計算リソース** ——MicrosoftのAzureクラウドは、OpenAIがモデルを訓練・提供するインフラの大部分を提供しています。 - **流通** ——OpenAIのモデルはMicrosoftのプラットフォーム(AzureのAIサービス、Copilot製品)を通じて提供され、MicrosoftのGPTの巨大な企業顧客基盤の前に置かれます。 - **収益分配** ——両社は商業契約の下で収益を分配しており、MicrosoftはOpenAIに多額の投資を行っています。 このパートナーシップは一部が資本、一部がGTM(市場投入)です。直接販売すれば何年もかかるような企業へのアクセスをOpenAIに与えています。 ### 5. 新規および隣接製品 OpenAIは収益化できる面を拡大し続けています。 - **Codex** ——エージェント型コーディングツール。サブスクリプションとAPI利用で収益化(大量のトークン消費のドライバーでもあります)。 - **Sora** ——動画生成。有料プランの内部および独立した製品として提供。 - **画像生成およびその他のモダリティ** ——サブスクリプションにバンドルされ、API経由で従量課金。 - **開発者・エージェントエコシステム** ——カスタムGPT、エージェントプラットフォーム、企業がOpenAIのモデル上に構築できるツール群。 これらはいずれも同じコアアセットの別の包装であり、ユーザーと開発者が喜んで支払う価値の最大化を目指しています。 ## OpenAIは黒字なのか? OpenAIは非公開企業であり、監査済みの財務諸表は公開していません。広く伝えられている状況:**収益は非常に大きく急速に成長しているが、コストも同様**——フロンティアモデルの訓練と数億人のユーザーへのサービスは驚異的な計算コストを消費します。競合他社と同様、OpenAIは成長と能力を最優先にする大規模投資フェーズにあり、短期的な利益は目標ではありません。この賭けは、規模と企業採用の拡大が計算コストをいずれ上回るというものです。 ## Anthropicとの比較 基本要素は似ています——消費者向けサブスクリプション、従量課金API、企業契約、コーディングツール——しかし重点が異なります。OpenAIの決定的な優位性は**消費者規模**(ChatGPT)と**Microsoft**パートナーシップです。AnthropicはAmazonとGoogleの支援を受け、**開発者・企業API**により大きく傾いています。比較の逆側については、[Anthropicがどうやって収益を得ているか](https://alejandrorioja.com/how-does-anthropic-make-money/)をご覧ください。 ## OpenAI収益モデル——2026年FAQ ### OpenAIの最大の収益源は何ですか? **ChatGPTのサブスクリプション。** ChatGPTが数億人のユーザーにリーチしているため、有料プラン(Plus・Pro・Team・Enterprise・Edu)がOpenAIの最大の収益ラインを構成しています——消費者よりもAPIや企業から多く稼ぐAIラボが多い中で、これは異色のプロフィールです。 ### OpenAIのAPIはどうやって収益を得ているのですか? 開発者は自社アプリでOpenAIのモデルを使用する際に**トークン単位**で支払います——処理されるテキスト・画像・音声の各チャンク単位で課金されます。より高性能なモデルはトークン単価が高く、出力は入力より高く設定されています。顧客の利用量が増えるにつれ、収益は自動的に増加します。 ### OpenAIは上場していますか?OpenAIの株を買えますか? いいえ。OpenAIは非公開企業であり、その株式は公開市場では取引されていません。ほとんどの人は直接投資することができません。MicrosoftはパートナーシップによってOpenAIに重要な出資をしていますが、それはOpenAIが上場しているということとは異なります。 ### MicrosoftとのパートナーシップはどのようにOpenAIに収益をもたらしているのですか? Microsoftはazure計算リソースを提供し、製品とクラウドを通じてOpenAIのモデルを巨大な企業顧客ベースに流通させ、両社は商業契約の下で収益を分配します。Microsoftはまた、OpenAIに多額の投資も行っています。資金源であると同時に流通チャネルでもあります。 ### OpenAIはChatGPTの無料ユーザーから収益を得ていますか? 直接的には得ていません——無料プランはファンネルです。収益は、無料ユーザーが**Plus**や**Pro**にアップグレードするとき、企業が**Team**や**Enterprise**のシートを購入するとき、そして開発者が**API**を使って構築するときに発生します。無料製品の役割はリーチの拡大であり、有料プランとAPIがそれを収益に変換します。 **関連記事:**[Anthropicはどうやって収益を得ているか](https://alejandrorioja.com/how-does-anthropic-make-money/) · [SpaceXはどうやって収益を得ているか](https://alejandrorioja.com/how-does-spacex-make-money/) · [AIエージェント入門ガイド](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) --- ## 短いまとめ OpenAIはChatGPTの膨大なユーザーベースをサブスクリプション収益(Plus・Pro・Team・Enterprise)に変換し、APIを通じて開発者にトークン単位で課金し、大規模な企業契約を締結し、Microsoftに計算リソース・流通・収益分配を依存しています。その決定的な特徴は消費者規模です。ほとんどのAIラボが開発者を最初に収益化するのに対し、OpenAIはまず消費者フェノメノンを作り上げ、その後にビジネスを構築しました。 --- ## SpaceXはどうやって収益を上げているのか?打ち上げ、Starlink、IPO問題 Source: https://alejandrorioja.com/ja/how-does-spacex-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business TL;DR: SpaceXは三つの方法で収益を上げています:打ち上げサービス(再利用可能なFalconロケットで軌道への搭乗権を販売)、Starlink(コンシューマー・企業・海事・航空・政府向け衛星インターネット)、そして政府契約(NASAの有人・貨物輸送、月面着陸システム、国家安全保障関連打ち上げ)。Starlinkは現在、最大の収益源です。SpaceXは非公開企業のままで、SpaceX自体のIPOは差し迫っていませんが、将来的なStarlinkのスピンオフ上場は長年議論されています。 ## Table of contents _2026年6月更新。_ **TL;DR:** SpaceXは三つの方法で収益を上げています:**打ち上げサービス**(再利用可能なFalconロケットで軌道への搭乗権を販売)、**Starlink**(コンシューマー・企業・海事・航空・政府向け衛星インターネット)、そして**政府契約**(NASAの有人・貨物輸送、月面着陸システム、国家安全保障関連打ち上げ)。Starlinkは現在、最大の収益源です。SpaceXは非公開企業のままで、SpaceX自体のIPOは差し迫っていませんが、将来的なStarlinkのスピンオフ上場は長年議論され、繰り返し否定されてきました。 **【オペレーターの見解】** SpaceXは、ハード技術の堀(再利用可能なロケット)を活用してソフトウェア経済型ビジネス(衛星インターネット)をその上に構築した、現代における最も明確な事例です。打ち上げビジネスは存在権を獲得するためのもの、Starlinkは継続的でスケーラブルな収益が生まれる場所です。これが一文で表したすべての話です。 ## SpaceXとは SpaceX(スペース・エクスプロレーション・テクノロジーズ)はロケットと宇宙船を設計・製造・運用し、Starlink衛星インターネットネットワークを運営しています。2002年に人類を多惑星種にするという長期的な目標のもとに設立され、他の誰も規模において成し遂げなかったこと——軌道ロケットの第一段を着陸・再利用すること——を実現することで、宇宙へのアクセスコストを劇的に下げ、世界の主要打ち上げプロバイダーとなりました。 このコスト優位性がほかのすべての原動力です。安価で頻繁かつ信頼性の高い打ち上げが、7,000機以上の衛星コンステレーションを経済的に可能にしており、そのコンステレーションが、不均一なプロジェクトベースの打ち上げビジネスを継続的収益モデルに転換させています。 ## SpaceXはどうやって収益を上げているのか? ### 1. 打ち上げサービス 最初のビジネスです。SpaceXは三種類の顧客に打ち上げを販売しています: - **商業衛星オペレーター**——軌道上にペイロードを必要とする企業は、専用打ち上げの費用を支払うか、**ライドシェア**ミッション(1機のロケットに多数の小型衛星を搭載し、キログラム単価で料金設定)のスロットを購入します。 - **政府および軍**——国家安全保障ペイロードや科学ミッションで、信頼性と保証のためにプレミアムが付くことが多いです。 - **他の宇宙企業**——SpaceXが最安値で最も利用可能な打ち上げ手段であるため、ますます競合他社も依存するようになっています。 ユニットエコノミクスが成立するのは**再利用性**のおかげです。同一の第一段ブースターが何度も飛行するため、1回の打ち上げの限界コストは価格をはるかに下回ります。Falcon 9が主力機、Falcon Heavyが最重量ペイロードを担当します。 ### 2. Starlink(継続的収益マシン) Starlinkは、地上ブロードバンドが届かない、またはサービスされていない場所に高速インターネットを提供する、数千機の低地球軌道衛星のコンステレーションです。今やSpaceXの中で本物のサブスクリプションビジネスに最も近い部門で、複数の層で構成されています: - **コンシューマー**——家庭がディッシュ(ハードウェア)と月額サブスクリプションを支払います。 - **エンタープライズとモビリティ**——企業、海事(船舶、ヨット)、**航空**(航空会社との機内Wi-Fiディール)向けの高価格プラン。 - **政府**——軍事・政府顧客向けの防衛志向バリアントである**Starshield**を含みます。 - **ダイレクト・トゥ・セル**——不感地帯の一般携帯電話に衛星接続を直接提供するための、携帯キャリアとのパートナーシップ。 Starlinkはハードウェア販売(端末)と何百万もの加入者からの毎月の継続的収益(サブスクリプション)を組み合わせます——惑星規模で展開される古典的な「カミソリと替刃」型モデルです。だからこそ現在の大多数の推計では、Starlinkが打ち上げを上回りSpaceX最大の収益ラインになっています。 ### 3. 政府契約 打ち上げと重複しますが、切り分けて考える価値のある、独立した非常に大きなセグメントです: - **NASA**——SpaceXは**Commercial Crew**プログラム(Crew Dragon)で宇宙飛行士を国際宇宙ステーションに送り届け、**Cargo Dragon**でISSへの補給を行っています。また、NASAの月探査計画向けに**Starship**ベースの有人月面着陸システムを製造する契約も獲得しました。 - **国家安全保障**——防衛・情報機関ペイロード向けの定期打ち上げ契約。 これらの契約は高額かつ複数年にわたり、商業側に恩恵をもたらす多くの開発資金を賄っています。 ### 4. Starship(未来のエンジン、まだ利益の柱ではない) Starshipは完全再利用型の超大型ロケットで、Falconの長期的な後継機であり、月/火星ミッションと次世代の大型Starlink衛星両方の鍵を握っています。現在はほかの三事業から資金提供を受けるコストセンターです。定期飛行に到達すれば、再び打ち上げコストを大幅に下げ、はるかに大規模なStarlinkの展開を可能にします——これが投資家が実際に賭けているシナリオです。 ## SpaceXは黒字ですか? SpaceXは非公開企業で監査済み財務諸表を公開していないため、正確な数字はいずれも推計です。広く伝えられている全体像:再利用性のおかげで打ち上げはミッション単位で黒字であり、加入者基盤の拡大とともにStarlinkはキャッシュフロー黒字へ転換しました。同社はStarship開発に莫大な資金を再投資しており、「利益」はこの研究開発費をどう扱うかに大きく依存します。発展の方向性——支配的な打ち上げビジネスの上に積み上がる拡大中のStarlink継続的収益——が同社の巨大な非公開評価額を支えています。 ## IPO問題 誰もが質問するこの話題について、率直な版をお伝えします。 **SpaceX自体の近いIPOは期待されていません。** Elon MuskはStarshipと火星プログラムが資本集約的で長期的な視野を必要とする間は、SpaceXを非公開にしたいと繰り返し述べています——公開市場の四半期プレッシャーは数十年単位のミッションには馴染みません。その代わり、SpaceXは定期的な**テンダーオファー**(会社が一定価格で株式売却を仲介)を通じて従業員と初期投資家に流動性を提供しており、公開上場なしで換金できるようにしています。これらの二次売却が見出し評価額を生み出しており、SpaceXは最近のラウンドで数千億ドル規模の評価を受けています。 **Starlinkのスピンオフ上場は長年議論されています**——Musk自身、数年前にStarlinkの収益が安定して予測可能になれば上場を検討する可能性があると示唆しました。しかし近い将来のタイムラインについては繰り返し否定的です。2026年時点でStarlinkはIPOしておらず、確定日もありません。「Starlink IPO日」という見出しは、会社自身から発信されていない限り懐疑的に見てください。 ## まとめ SpaceXのモデルはスタックです:再利用可能な打ち上げがコストの堀を築き、その堀がStarlinkを経済的に可能にし、Starlinkがすべてを継続的収益ビジネスに変え、政府契約がコスト曲線を再びリセットする最前線の仕事(Starship)に資金を提供します。同社は意図的に非公開を維持し、IPOの代わりにテンダーオファーを活用しています——そして公開市場への最も可能性の高い道は、SpaceX全体ではなく将来的なStarlinkの単独上場であり、そのタイミングは会社が適切と判断した時です。 ## SpaceX収益モデル——2026年よくある質問 ### SpaceXの最大の収益源は何ですか? 現在の大多数の推計では**Starlink**が打ち上げサービスを上回り、SpaceX最大の収益ラインとなっており、数百万件のコンシューマー・企業・モビリティ・政府向けサブスクリプションと端末ハードウェア販売が原動力です。打ち上げサービスも依然として大規模でミッション単位では高収益ですが、Starlinkの継続的モデルの方が速くスケールします。 ### SpaceXは上場していますか?SpaceX株を買えますか? いいえ。SpaceXは非公開企業であり、その株式は公開証券取引所では購入できません。一般の方が直接投資することはほぼできず、アクセスは通常、プライベートラウンドやテンダーオファーに参加する従業員と適格投資家に限定されます。そうでないことを示唆する「SpaceX株」の売り込みには注意が必要です。 ### SpaceXまたはStarlinkはIPOしますか? SpaceXが近い将来に上場することは期待されていません——Muskは資本集約的なStarship/火星フェーズの間は非公開にしておきたいと述べています。**Starlink**のIPOは収益が予測可能になれば可能性があるものとして長年議論されてきましたが、2026年時点では確定日はありません。具体的な「IPO日」の主張は、会社からのものでない限り懐疑的に扱うべきです。 ### Starlinkはどうやって収益を上げているのですか? Starlinkは顧客に衛星ディッシュ(ハードウェア)と月額サブスクリプションを請求し、コンシューマー・ビジネス・海事・航空・政府の各層をカバーしています——防衛志向のStarshieldとダイレクト・トゥ・セルのキャリアパートナーシップを含みます。カミソリと替刃モデルです:ハードウェアを先に、継続的収益は後で。 ### 再利用性はSpaceXの利益にどう貢献していますか? 同じロケットブースターを何度も着陸・再飛行させることで、各打ち上げの限界コストが請求価格を大幅に下回ります。このコスト優位性がSpaceXを最安の打ち上げプロバイダーたらしめており、数千機のStarlinkコンステレーションを展開することを経済的に実現可能にしています。 **関連記事:** [Uberはどうやって収益を上げているのか](https://alejandrorioja.com/how-does-uber-make-money/) · [Shopifyの収益モデル](https://alejandrorioja.com/how-shopify-makes-money/) · [PayPalはどうやって収益を上げているのか](https://alejandrorioja.com/how-does-paypal-make-money/) --- ## 短いまとめ SpaceXはロケットを再利用することで安価に軌道への搭乗権を販売し、そのコスト優位性を活かしてStarlinkを運営しています——衛星インターネットのサブスクリプションビジネスとして今や最大の収益源です——政府契約は次世代Starshipに資金を提供します。同社は意図的に非公開を維持しており;SpaceX全体ではなくStarlinkのIPOが、公開市場への最終的な最も可能性の高い経路です。 --- ## Claudeのスケジュールタスクの使い方:cronで繰り返し作業を自動化する Source: https://alejandrorioja.com/ja/how-to-use-claude-scheduled-tasks/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: スケジュールタスクは、一回限りのClaudeプロンプトを繰り返しジョブに変えます。cronスタイルのスケジュールで起動し、作業を実行して結果を届けます。個人の定期プロンプト(朝のダイジェスト、週次サマリー)にはClaudeアプリを、クラウドで動く開発者向け自動化にはClaude Codeルーティンまたは Managed Agentsデプロイを使いましょう。毎日・毎週手作業で繰り返していた作業を自動化することで大きな効果が得られます。 ## Table of contents _2026年6月更新。_ **TL;DR:**スケジュールタスクは、一回限りのClaudeプロンプトを繰り返しジョブに変えます。cronスタイルのスケジュールで起動し、作業を実行して結果を届けます。個人の定期プロンプト(朝のダイジェスト、週次サマリー)には**Claudeアプリ**を、クラウドで動く開発者向け自動化には**Claude Codeルーティン**または**Managed Agentsデプロイ**を使いましょう。毎日・毎週手作業で繰り返していた作業を自動化することで大きな効果が得られます。 **【オペレーター向け】** 最もレバレッジの高い自動化は派手ではありません——毎日静かに20分を奪っていく小さな繰り返しジョブです。スケジュールタスクとは、そういった作業をClaudeに一度だけ渡して、二度と気にしなくて済む仕組みです。私はいくつか運用しています:朝の競合スキャン、夜間のPRステータス確認、週次のコンテンツパイプライン草稿。どれも設定に10分もかかりませんでした。 ## スケジュールタスクとは 通常のClaude セッションは同期的です:あなたが入力し、応答があり、あなたはそこにいます。**スケジュールタスク**は非同期かつ繰り返しです:プロンプト(またはエージェントワークフロー全体)とスケジュールを定義すると、Claudeが自律的に実行します——平日の毎朝7時、毎週月曜日、毎時間——そして完了したら結果を渡します。 内部的にはLLMを中心に据えたcronジョブです。APIを繋ぎ合わせるコードを書く必要はなく、結果を日本語で説明するだけで、エージェントが毎回の起動時にステップを自分で解決します。 ## 設定する3つの場所 ボタンが一つあるわけではありません——利用者に応じた3つの入口があります。 ### 1. Claudeアプリ(誰でも使える) コンシューマー向けClaude アプリは繰り返しタスクをサポートしています:プロンプトとスケジュールを保存すると、Claudeがスケジュール通りに実行し、結果を通知します。これがノーコードの方法です——毎日のブリーフィング、定期的なリサーチ、「毎朝未読のニュースレターを要約する」といった用途に最適です。開発者でなければ、ここから始めましょう。 ### 2. Claude Codeルーティン(ターミナル常駐ユーザー向け) **Claude Code**を使っている場合、プロンプトやスラッシュコマンドをcronスケジュールでクラウドエージェントとして実行するよう設定できます——これが「ルーティン」です。リポジトリやワークスペース上でサーバーサイドで動くので、ラップトップを閉じていても機能します。典型的な使い方:オープンなプルリクエストの監視、夜間のlint・修正パス実行、毎朝レビュー用の草稿投稿生成。スケジュールとタスクを定義すれば、Claude Codeが起動と実行記録を管理します。 ### 3. Managed Agentsデプロイ(製品を構築する開発者向け) Claude API上で構築しているチームには、**スケジュールデプロイ**があります。繰り返しのcronスケジュールでエージェントを実行します——各起動でセッションが立ち上がり、自律的に作業を行います(夜間のコンプライアンススキャン、週次レポート、時間ごとの監視)。起動ごとの実行記録で成功と失敗を監査できます。これは同じアイデアのプログラマティックでプロダクションレベルのバージョンです。 ## スケジュールについての考え方 3つすべてが同じメンタルモデルを使います——**どんなタスクを、どれくらいの頻度で、出力はどうするか**: 1. **タスク** ——優れたエージェントプロンプトを書くように記述します:役割、コンテキスト、正確なアクション、制約、そして確認事項。スケジュールタスクは実行中に確認の質問ができないため、*最初から完全に指定*する必要があります。これがインタラクティブな使用との最大の違いです。 2. **ケイデンス** ——毎日、毎週、毎時間、平日のみ、タイムゾーンの特定の時間。実際に対象が変化する速度に合わせましょう。週次更新のソースに「毎日」のダイジェストを設定するのは無駄な実行です。 3. **デリバリー** ——結果が届く場所(通知、ファイル、メッセージ、草稿)。出力が届いた瞬間に役立つよう、事前に決めておきましょう。 ## 実際に効果的なパターン - **朝のダイジェスト。**「平日の毎朝7時に、[トピック]の最新情報を取得し、重要な3点を要約して、5つの箇条書きのブリーフを送って。」手動スキャンの20分を置き換えます。 - **週次レポート。**「毎週月曜日に、[指標]を1ページのサマリーにまとめ、何が変わったか、なぜかを含めて。」繰り返しの雑務をレビューに変えます。 - **夜間ワーカー。**あなたが寝ている間に長く、詳細に指定された作業を実行するコードルーティン——リファクタリング、テストスイープ、データクリーンアップ——目覚めたらレビュー可能な結果が届きます。 - **モニター。**「毎時間[事項]を確認し、[条件]が真の場合のみ連絡して。」最良の自動化はほとんど沈黙し、重要な時だけ声を上げます。 ## 本番運用から得た設定のコツ - **プロンプトを過剰に詳細に書く。**実行中に確認の質問はできません。フォーマット、ソース、制約、エッジケースの対処法を明記しましょう。 - **まず手動テストをする。**正確なプロンプトを一度手動で実行します。インタラクティブに望む結果が出れば、スケジュール設定します。出なければ、まずプロンプトを修正しましょう——悪いプロンプトをスケジュールしても、安定して悪い出力を生むだけです。 - **ケイデンスを変化率に合わせる。**週次更新のものに対して時間ごとの実行を設定しない。 - **リスクが高い場合は出力を草稿として保持する。**外部に出るもの——公開投稿、送信メール——はライブアクションではなく、レビュー用の*草稿*を生成するよう設定しましょう。完全自律の「とにかくやって」は、低リスクで元に戻せる作業に限定します。 - **最初のいくつかの実行を監視する。**スケジュールジョブはずれていきます——ソースがフォーマットを変え、フィードが静かになります。初期の実行記録を確認してから信頼しましょう。 ## Claudeスケジュールタスク——2026年FAQ ### Claudeのスケジュールタスクとは何ですか? 繰り返しジョブです:プロンプトまたはエージェントワークフローとcronスタイルのスケジュールを定義すると、Claudeが自動的に実行します——毎日、毎週、毎時間——キーボードの前にいなくても結果を届けます。コンシューマー向けClaude アプリ(個人の定期プロンプト用)、Claude Code(クラウドルーティンとして)、Claude API(Managed Agentsデプロイとして)に存在します。 ### 使うために開発者である必要はありますか? いいえ。Claudeアプリはコードなしで繰り返しタスクをサポートしています——保存されたプロンプトとケイデンスだけで使えます。Claude Codeルーティンと Managed Agentsデプロイは、コードと製品ワークフローを自動化する開発者向けバージョンです。 ### スケジュールタスクは通常のClaude チャットとどう違いますか? 通常のチャットはインタラクティブです——あなたがそこにいてフォローアップの質問に答えます。スケジュールタスクは自律的かつ繰り返しのため、プロンプトは最初から完全に指定する必要があります。Claudeは実行中に一時停止して質問することはできません。スケジュール通りに起動し、作業を完了し、結果をあなたに渡します。 ### 最初のスケジュールタスクに何が適していますか? 朝のダイジェストです。「平日の毎朝7時に、[あなたのトピック]の最新情報を5つの箇条書きで要約して。」リスクが低く、確認しやすく、繰り返しの手作業をすぐに置き換えられます——より大きなものを自動化する前にワークフローを学ぶための完璧なテンプレートです。 ### スケジュールタスクはメール送信などの実際のアクションを実行できますか? はい、ただし意図的に。元に戻せる低リスクの作業は実行させましょう。外部向けや元に戻しにくいものについては、自動的に実行するのではなく、あなたが承認する草稿を生成するよう設定しましょう——特に無人実行の際は。どれだけの自主性を与えるかは、元に戻せるかどうかが正しい判断基準です。 **関連記事:**[AIエージェント入門ガイド](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Anthropicはどのように収益を得ているか](https://alejandrorioja.com/how-does-anthropic-make-money/) · [ChatGPTの回答に引用される方法](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- **繰り返し作業を管理するスケジュールエージェントシステムが欲しいですか?**それがまさに私が構築しているものです——[お問い合わせください](https://alejandrorioja.com/contact/)。 --- ## AIエージェントのコスト計算:Haiku が Sonnet に勝つとき(勝たないとき) Source: https://alejandrorioja.com/ja/ai-agent-cost-math-when-haiku-beats-sonnet/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Sonnet ではなく Claude Haiku を選べば呼び出しあたりのコストを劇的に下げられますが、それはタスクが低い成功率を許容できる場合に限ります。本当の指標は呼び出しあたりのコストではなく、リトライと人手による後始末まで含めた「成功した結果あたりのコスト」です。私はデフォルトではなく、タスクごとにルーティングします。 ## 目次 _2026年6月更新。_ **要点:** Sonnet ではなく Claude Haiku を選べば呼び出しあたりのコストを一桁下げられますが、それはタスクが Haiku の低い成功率を許容できる場合に限ります。重要な指標は**成功した結果あたりのコスト** — 呼び出しコストにリトライと人手による後始末を加えたもの — であって、トークンあたりの表示価格ではありません。私はタスクごとにルーティングしており、判断を要する処理は Sonnet に残しつつ、高ボリュームのステップの相当な割合を Haiku で動かしています。 **運用者の視点:** 私は100以上のエージェントを運用しており、推論は実際の費目です。しかし、すべてを最安のモデルに押し込んで「節約した」つもりが、リトライ・エスカレーション・怒った顧客という形でコストを払うチームを何度も見てきました。コスト計算はファネル全体を測ってはじめて成立します。 最も安いモデルとは、トークンあたりの単価が最も低いモデルではありません。仕事を正しく終わらせるための総コストが最も低いモデルです。これらは別々の数字であり、その差こそが、エージェントのコスト判断の多くが誤る場所です。 ## トークンの経済性を、率直に言うと Anthropic は Claude を100万トークン単位で課金し、入力と出力は別々に請求され、出力は入力の数倍のコストがかかります。正確な数字は時とともに変わるので、Anthropic の最新価格を確認してください — ただし判断を動かすのは**構造**です: - **Haiku** は安価で高速な階層 — ファミリー内で群を抜いてトークンあたりのコストが低い。 - **Sonnet** は中間 — Haiku よりは明らかに高く、Opus よりは明らかに安い。 - **Opus** は最も難しい推論のためのプレミアム階層。 ここから二つのことが導かれます。第一に、生成タスクでは出力トークンがコストを支配するため、冗長なモデルは同じトークン単価でもより高くつきます。第二に、Haiku と Sonnet のトークン単価の差は、高ボリュームのステップでは間違いなく請求額に表れるほど大きいということです。これが Haiku を選ぶ*根拠*です。次に、選ばない根拠を。 ## 本当に重要な指標:成功した結果あたりのコスト 呼び出しあたりのコストは見栄えだけの数字です。私が実際に使っている式はこちらです: ``` 成功あたりのコスト = (呼び出しコスト × 試行回数) + 後始末コスト ÷ 成功率 ``` ここで `試行回数` はリトライを織り込み、`後始末コスト` はすり抜けた失敗を人間が修正する期待コストです。これが比較に何をもたらすか見てください。 Haiku が呼び出しあたり Sonnet の約10分の1のコストだとします。あるタスクで Haiku が80%、Sonnet が98%成功するなら、呼び出しあたりの節約は莫大に見えます。しかし、Haiku の失敗ごとにリトライが1回発生し、10回に1回は実費のかかる人間がなお必要なら、後始末の項がトークンの節約を飲み込みかねません。リスクが低く高ボリュームのタスクでは、計算は圧倒的に Haiku に有利です。失敗すれば誤った顧客にメールが飛ぶようなタスクでは、完全に逆転しうるのです。 この判断は、モデルごとの成功率を測らずには下せません — それこそ[評価ハーネス](/the-eval-harness-i-use-to-ship-ai-agents/)が与えてくれるものです。同じ評価セットを両モデルに対して走らせ、同じ物差しで成功率を読み取ってください。 ## Haiku が決定的に勝つ場面 タスクが**狭く、構造化され、検証可能**なとき、Haiku が正解です: - **分類とルーティング** — 「この受信メッセージは予約か、苦情か、スパムか?」三つのバケツ、検証が容易、絶えず動く。一日中 Haiku で。 - **スキーマに基づく抽出** — テキストから日付・名前・金額を取り出し、Zod で検証する。出力がパースできれば、ほぼ確実に正しい。 - **短いリライトと整形** — トーンの調整、良いと分かっている入力の要約、データの正規化。 - **一次フィルタリング** — Haiku がトリアージし、曖昧なケースだけが Sonnet にエスカレートされる。これが最もレバレッジの高いパターンです。 共通する筋:Haiku のミスのコストは低く、ミスは安く検出できる。検証が安く、リスクが低いとき、安いモデルが勝ちます。 ## Sonnet がその価格に見合う場面 タスクが**オープンエンド、多段階、または間違えると高くつく**とき、Sonnet(時には Opus)は価値があります: - **マルチツールのエージェントループ**で、一つの誤ったツール呼び出しが連鎖する場合。高い推論の信頼性はステップを通じて積み上がります — [マルチエージェント・オーケストレーション](/multi-agent-orchestration-patterns-queues-state-handoffs/)で扱うオーケストレーションのパターンは、モデルが筋を見失わないことに依存しています。 - **顧客向けの生成**で、悪い出力がリトライだけでなく信頼を損なう場合。 - **検証そのものが難しいあらゆるもの。** 出力が正しいかを安く判定できないなら、頻繁に間違えるモデルを使う余裕はありません。 ここでの失敗はリトライ1回では済みません — 返金、解約する顧客、あるいは私の時間がかかります。それに比べれば、トークンあたりの割増は端数の誤差です。 ## 私が実際に出荷しているルーティングのルール エージェントごとに一つのモデルを選ぶことはしません。エージェント内で**タスク**ごとにルーティングし、たいていは安価な分類器がどの下流モデルが処理を担うかを決めます: ```typescript function pickModel(task: Task): string { // 安価・検証可能・高ボリューム → Haiku if (task.type === "classify" || task.type === "extract") { return "claude-haiku"; } // オープンエンドまたは顧客向け → Sonnet if (task.customerFacing || task.steps > 2) { return "claude-sonnet"; } return "claude-sonnet"; // デフォルトは安全な選択 } ``` ここには二つの原則が刻まれています。**デフォルトは安全なモデルに**、安いモデルではなく — コストは動くベースラインから*下げて*最適化するもので、壊れた状態から信頼性を*上げて*いくものではありません。そして**エスカレートせよ、賭けるな**:簡単な80%を Haiku に任せ、難しい20%を Sonnet に渡す。このハイブリッドは、どちらか一方のモデルだけですべてを動かすのにほぼ常に勝ります。 さらに上乗せできるプロンプトキャッシングもあります:システムプロンプトが大きく再利用される場合、キャッシングは階層にかかわらず入力コストを大幅に削減し、時には Sonnet を十分に安くして Haiku の問いそのものを無意味にします。 ## 自分のスタックからの具体例 高ボリュームの受信トリアージのステップを例にとります。何千回も動き、タスクは三分類で、ミスしてもアイテムがレビューキューに落ちるだけ — 検出が安く、リスクが低い。これは教科書どおりの Haiku タスクであり、Sonnet から外したことで、重要な結果に測定可能な悪影響を与えずに、そのステップのコストを目に見えて下げられました。 次に、実際の顧客への返信を起草するステップを取り上げます。ボリュームは低く、オープンエンドで、悪い下書きが出れば信頼を損ないます。これは Sonnet のままにします。同じエージェント、二つのモデル、リスクでルーティング。私は[AIエージェントが本当に機能しているかをどう測るか](/how-i-measure-whether-an-ai-agent-is-actually-working/)で述べているやり方で、両方の実行あたりコストと成功指標を見ています — そして、評価が「安いモデルでも成功率を維持できる」と告げてはじめて、そのステップを一段下げます。 ## よくある質問 ### 実務上、Claude Haiku は常に Sonnet より安いですか? トークンあたりでは、はい — 大きな差で。成功した結果あたりでは、常にではありません。Haiku の低い成功率がリトライと人手による後始末を招くと、ミスの検出や修正にコストがかかるタスクでは、総コストが Sonnet を上回ることがあります。 ### あるタスクで Haiku と Sonnet をどう選び分けますか? タスクを二つの軸で採点します:出力がどれだけ検証可能か、そしてミスがどれだけ高くつくか。検証が安く、低リスクで高ボリュームの仕事は Haiku へ;オープンエンド、顧客向け、または検証が難しい仕事は Sonnet へ。エージェントごとではなく、タスクごとにルーティングします。 ### 追うべき唯一のコスト指標は何ですか? 成功した結果あたりのコスト — 呼び出しコスト掛ける試行回数に期待後始末コストを足し、成功率で割ったもの。呼び出しあたりの価格だけではリトライと人間の時間が隠れてしまい、そこで安いモデルが知らぬ間に高くつきます。 ### 一つのエージェントで両方のモデルを使えますか? はい、たいていはそうすべきです。最も強力なパターンは、安価な一次処理(Haiku が分類またはフィルタ)が曖昧なケースだけを Sonnet にエスカレートするものです。このハイブリッドは、単一の階層ですべてを動かすのに通常は勝ります。 --- ## 本番環境でAIエージェントをデバッグする方法(実践ガイド) Source: https://alejandrorioja.com/ja/how-to-debug-an-ai-agent-in-production/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: 本番のAIエージェントのデバッグは、どのレイヤーが故障したか — プロンプト、ツール、モデル、オーケストレーション — を切り分けることがほとんどだ。私はすべてのステップをトレースIDで記録し、まったく同じ入力をリプレイし、二分探索する。私のエージェントでは、'AIのバグ'の約70%はモデルのバグではなく配管のバグだと判明する。 ## 目次 _2026年6月更新。_ **TL;DR:** 本番のAIエージェントのデバッグは、どのレイヤーが故障したか — プロンプト、ツール呼び出し、モデル出力、オーケストレーション — を切り分けることがほとんどだ。私はすべてのステップをトレースIDで記録し、まったく同じ入力をリプレイし、そこから二分探索する。私のエージェントでは、「AIのバグ」に見えるもののおよそ70%は配管だと判明する — 不正な形式のツール結果、切り詰められた入力、黙って飲み込まれた例外だ。 **オペレーターの視点:** 私は100以上の本番エージェントを運用している — Picklelandの予約フロー、コンテンツパイプライン、受信トレイの仕分け係だ。それらはあらゆるソフトウェアが壊れるように壊れ、加えていくつか新しい壊れ方をする。これは私が持っていればよかったと思う実践ガイドだ。トークンの壁を凝視せずに、故障しているレイヤーを見つける方法である。 エージェントが本番で誤動作すると、本能的にモデルを責めたくなる。「Claudeが幻覚を起こした」。時には本当だ。たいていは違う。モデルは5層か6層のスタックの中の一つのレイヤーであり、バグはAnthropicが出荷したレイヤーよりも、あなたが書いたレイヤーにあることのほうがはるかに多い。この記事は、私がそれを見つける体系的な方法である。 ## 何かをデバッグする前に、すべての実行をトレース可能にする 見えないものはデバッグできない。最も効果の高いこと — 特定のバグが現れる前に — は、すべてのエージェント実行にトレースIDを付与し、それが踏むすべてのステップを記録することだ。 「ステップ」とは境界を越えるあらゆるものだ。受信トリガー、各モデル呼び出し(完全なメッセージ配列付き)、各ツール呼び出し(引数付き)、各ツール結果、そして最終出力。それらをトレースIDをキーとする構造化JSONとして記録する。 ```typescript function logStep(traceId: string, step: string, payload: unknown) { console.log(JSON.stringify({ traceId, step, // "trigger" | "model_call" | "tool_call" | "tool_result" | "output" ts: Date.now(), payload, })); } ``` Cloudflare Workersではこれらをキューとテーブルに送り、ローカルではstdoutに出す。ルールは絶対だ。ステップが記録されていなければ、デバッグに関する限りそれは起きなかったことになる。これは[私が使うエージェントスタック](/the-agent-stack-i-use-to-run-30-production-agents-no-python/)で述べた計装を反映している — トレースIDは他のすべてがぶら下がる背骨だ。 ## レイヤーを切り分ける:プロンプト、ツール、モデル、オーケストレーション トレースさえあれば、デバッグは二分探索になる。レイヤーは4つあり、バグはたいていそのうちのちょうど一つに潜んでいる。 ### 1. 入力レイヤー(最もよくある原因) 故障したモデル呼び出しに入った、まったく同じ `messages` 配列を取り出す。再構築ではなく — ログからの文字どおりのペイロードだ。それを、見知らぬ人が読むように読む。「モデルが指示を無視した」という私のバグの半分は、実際には次のものだ。 - 何かが誤って文字列化されたために `"[object Object]"` として返ってきたツール結果。 - コンテキストウィンドウを超過し、素朴なスライスが切り取ったために文の途中で切り詰められた入力。 - `undefined` として補間され、こっそりプロンプトを汚染した変数。 入力が間違っていれば、モデルはゴミに対して完璧に仕事をしたのだ。配管を直そう。 ### 2. ツールレイヤー 入力がきれいに見えるなら、エージェントが成功として扱ったエラーをツールが返していないか確認する。古典的な例:APIが `{ "error": "rate limited" }` という本文付きで `200` を返し、あなたのツールラッパーが本文を確認せず、エージェントが自信満々にエラーメッセージに基づいて動く。ツール結果を生のまま記録し、その形を検証しよう。 ### 3. モデルレイヤー 1と2を除外して初めて、私はモデルを疑う。それでも、「モデルのバグ」はたいてい「私のプロンプトが曖昧だ」を意味する。故障したまったく同じ入力を取り、同じモデルと温度に対して使い捨てのスクリプトに投入し、再現するか見る。再現するなら、修正はプロンプト作業か[より厳密なeval](/the-eval-harness-i-use-to-ship-ai-agents/)であって、慌ててモデルを差し替えることではない。 ### 4. オーケストレーションレイヤー 単一のステップが単独では問題ないのに複数ステップの実行が失敗するなら、バグは引き継ぎにある — ステップ間で失われた状態、競合状態、冪等でないアクションを再実行したリトライだ。これらが最も厄介で、私は[マルチエージェント・オーケストレーションのパターン](/multi-agent-orchestration-patterns-queues-state-handoffs/)でそのパターンを扱っている。 ## 非決定性と戦うのではなく再現する エージェントをデバッグ不能に感じさせるのは非決定性だ。同じ入力が実行ごとに異なる出力を生む。これは飼いならせる。 第一に、**固定できるものを固定する。** デバッグ中は `temperature: 0` に設定する。Claudeを完全に決定論的にはしないが、分散を大幅に狭めるので、本物のバグをサンプリングノイズと見分けられる。 第二に、**N回実行する。** 失敗が20回に1回再現するなら、まったく同じ入力を50回ループさせ、すべての出力を捕捉する。これで逸話ではなくサンプルが手に入る。5%の確率で発火するバグは本物のバグだ — それを見るには量が必要なだけだ。 ```bash for i in $(seq 1 50); do node replay.mjs --trace=abc123 >> runs.jsonl done # それから失敗を数える grep -c '"status":"fail"' runs.jsonl ``` 第三に、**成功した実行と失敗した実行を差分する。** 温度を固定し同じ入力なら、出力の違いは、あなたがまだ見つけていない入力の違いを意味する — プロンプト内のタイムスタンプ、変動するツール結果、変わってしまった取得済みドキュメントだ。 ## リプレイハーネスを作り、本番でのデバッグをやめる 稼働中のエージェントを再トリガーしてデバッグするのは遅くて危険だ — 実際のメールを送り、実際のコートを予約してしまう。代わりに、トレースを捕捉してオフラインでリプレイする。 リプレイハーネスは記録済みトレースを読み込み、任意のステップへのまったく同じ入力を再構築し、そのステップだけをモデルに対して再実行する。完全な `messages` 配列を記録してあるので、上流システムはまったく必要ない。これは本番での10分の往復を2秒のローカルループに変え、私のデバッグワークフローにおける最大の高速化だ。 良いリプレイハーネスは**変異させて再実行する**こともできる。システムプロンプトの1行を変え、同じ50の失敗トレースをリプレイし、いま何件が通るか見る。これがデバッグからevalへの架け橋だ — 失敗トレースのコーパスができれば、回帰スイートの始まりが手に入る。 ## 故障を実際に予測するメトリクスを監視する 一部の失敗は決して例外を投げない。エージェントは実行され、もっともらしいものを返し、こっそり間違ったことをする。それらを捕まえるには、エラー率だけでなく挙動メトリクスを監視する。 - **ツール呼び出し成功率**(ツールごと)。ここでの低下はしばしば目に見える失敗に先行する。 - **出力スキーマの妥当性** — 出力の何%が期待される構造に対してパースできるか。私はすべての出力をZodで検証し、妥当性が下がったらアラートを出す。 - **ループ長** — 実行あたりの平均ステップ数。急なスパイクはたいてい、エージェントがリトライで詰まっていることを意味する。 - **実行あたりのコスト** — 暴走ループは、苦情として現れる前にコストのスパイクとして現れる。(コストが重要なときは、[HaikuとSonnetの計算](/ai-agent-cost-math-when-haiku-beats-sonnet)を知っておく価値がある。) 私はこれらを他のすべてと同じように追跡する — [AIエージェントが実際に機能しているかをどう測るか](/how-i-measure-whether-an-ai-agent-is-actually-working/)を参照。静かな失敗を捕まえるメトリクスは、騒がしい失敗を捕まえるもの10個分の価値がある。 ## 5分のトリアージ・チェックリスト エージェントが壊れて時間に追われているとき、私はこれを順番に実行する。 1. 失敗した実行の**トレースIDを取得する。** 2. 失敗したステップへの**まったく同じ入力を読む。** 整形式か?(ここで約50%のケースが解決する。) 3. そのトレース内の**ツール結果を確認し、**成功を装ったエラーがないか調べる。 4. `temperature: 0` で**ステップをオフラインでリプレイする。** 再現するか? 5. **再現するなら、**プロンプト/モデルの問題だ — 修正してトレースコーパスを再実行する。**しないなら、**非決定性か状態/オーケストレーションのバグだ — 50回ループさせて特徴づける。 規律ある切り分けは、巧妙なプロンプティングに毎回勝る。モデルが問題であることはまれだ。たいてい問題はその周りのシステムにある。 ## よくある質問 ### たまにしか失敗しないAIエージェントはどうデバッグしますか? 記録済みトレースからまったく同じ入力を捕捉し、温度0で50回以上リプレイする。断続的な失敗は発火率の低い本物のバグだ — 量が逸話を、差分して修正できる再現可能なサンプルに変える。 ### バグはたいていモデルにありますか、それとも私のコードにありますか? 私の本番エージェントでは、見かけ上の「AIのバグ」のおよそ70%は配管だ。不正な形式のツール結果、切り詰められた入力、飲み込まれた例外、ステップ間で失われた状態。モデルを疑う前に、入力レイヤーとツールレイヤーを除外しよう。 ### エージェントをデバッグするのに必要な最小限のロギングは? すべての実行のトレースID、加えてトリガー、各モデル呼び出し(完全なメッセージ配列)、各ツール呼び出しとその生の結果、そして最終出力の構造化ログ。ステップが記録されていなければ、それはデバッグできない。 ### 稼働中の本番に対するデバッグをやめるには? 記録済みトレースを読み込み、捕捉した入力を使って任意の単一ステップをオフラインで再実行するリプレイハーネスを作る。それは遅くて危険な本番の往復を速いローカルループに変え、回帰スイートの種になる。 --- ## AI検索が本当にトラフィックを送っているかを測定する方法 Source: https://alejandrorioja.com/ja/how-to-measure-ai-search-traffic/ Published: 2026-06-08 Tags: GEO, Analytics TL;DR: AI検索トラフィックの大半は、chatgpt.com、perplexity.ai、claude.aiからのわずかなリファラルとして現れます——しかしより大きな影響はダークです。人々はAIの回答を読み、決してクリックしません。私は両方を測定し、クリックにはリファラーを、影響にはブランド検索の上昇を使います。 ## 目次 _2026年6月更新。_ **TL;DR:** AI検索トラフィックの大半は、`chatgpt.com`、`perplexity.ai`、`claude.ai`からの細い流れのリファラルとして到着します——どこを見ればよいか分かれば数えるのは簡単です。しかしより大きな影響は**ダーク**です。人々はAIの回答を読み、あなたのブランドを吸収し、決してクリックしません。私はクリックをリファラーセグメントで、影響をブランド検索の上昇、ダイレクトトラフィックの変化、引用モニタリングで追跡します。クリックだけを数えると、AI検索を著しく過小評価します。 **運用者の視点:** 私はコンテンツエンジンを運営し、その分析を毎日見ています。「AI検索はトラフィックを送っているか?」という問いには、もどかしい答えがあります——はい、ですが価値の大半はあなたのセッションレポートには現れません。ここでは、現れる部分をどう測定し、現れない部分をどう推測するかを示します。 誰もが一つの数字を求めます——「ChatGPTはどれだけのトラフィックを送ってくれているのか?」。正直な答えは、AI検索は2つの非常に異なる効果を生み出し、2つの異なる測定が必要だということです。これらを混同すれば、パニックに陥る(クリックが極小に見える)か、自分を欺く(本当の影響を見逃す)かのどちらかになります。 ## 効果1: ダイレクトリファラル——数えられるが、期待より小さい 誰かがChatGPT、Perplexity、またはClaudeの回答内の引用をクリックすると、あなたの分析はリファラーを記録します。これらは実在する、帰属可能なセッションです。GA4または任意の分析ツールで、AIエンジンを捕捉するセグメントを構築します: ``` session source matches any of: chatgpt.com chat.openai.com perplexity.ai claude.ai gemini.google.com copilot.microsoft.com ``` これを「AI検索」チャネルとして保存し、時系列で観察します。人々がつまずくいくつかの注意点: - **リファラーは漏れる。** 一部のAIサーフェスはリファラーを除去または改変するため、本物のAIクリックの一部は代わりに「ダイレクト」に着地します。あなたのリファラル数は床であって、真実ではありません。 - **回答インプレッションに対して量が少ない。** AIエンジンはページ上で質問に答えます。クリックして進むのは好奇心旺盛な少数だけです。1日あたりわずかなリファラルが、あなたが引用されているのを見たはるかに多くの人々に対応している可能性があります。 ですからリファラルセグメントは必要だが不十分です。AI検索が*いくらか*のトラフィックを送っていることは教えてくれます。影響は著しく過小に数えます。 ## 効果2: ダークな影響——より大きく、見えにくい方の半分 本当の動きはゼロクリックです。誰かがChatGPTに質問し、あなたのブランドが回答の中に推奨ソースとして現れ、決してクリックしない——ただあなたを記憶するだけです。それは後に**ブランド検索**または**ダイレクト訪問**として現れ、何にも帰属されません。これは強調スニペットの測定を厄介にしたのと同じ力学が、増幅されたものです。 ダークな影響を直接測定することはできませんが、三角測量することはできます: 1. **ブランド検索ボリューム。** Google Search Consoleであなたの名前/ブランドの検索を時系列で追跡します。AIエンジンに引用され始め、対応するキャンペーンなしにブランドインプレッションが上昇すれば、その上昇はAIの影響の指紋です。 2. **ダイレクトトラフィックの傾向。** どのキャンペーンも追えない「ダイレクト」セッションの持続的な上昇は、しばしばリファラーを剥がされたAIリファラルと、AIの言及後にあなたを直接入力する人々を反映しています。 3. **アシストコンバージョン。** AI検索セッションが、たとえ稀でも、コンバージョンに至るジャーニーで*最初の*接点として現れるかを見ます。ラストクリックでは極小のチャネルも、ファーストタッチでは意味を持つことがあります。 これらのいずれもきれいな数字ではありません。合わせて見れば、ダークな半分が動いているかどうかを教えてくれます。 ## クリックだけでなく、引用を追跡する これがAI検索について私が最も気にかける指標で、あなたの分析にはまったく載っていません——**私は引用されているか、そしてどのクエリで?** ビジネスにとって重要な20〜40のクエリのリストを維持し、スケジュールに沿ってChatGPT、Perplexity、Claudeに通します——週次で十分です。各クエリとエンジンについて記録します——あなたは引用されているか、どの位置で? これはランクトラッキングのGEO版であり、先行指標です。引用は下流のトラフィックやブランドの上昇*より先に*動くので、ここで[ローカルビジネスのためのGEO作業](/geo-for-local-business-getting-a-brick-and-mortar-cited-by-ai-search/)が効いているかが見えます。 私はこれらのチェックを実行し結果を記録する小さなエージェントを作りました——エージェントスタックを持てば些細なことです。手作業でやりたければ、スプレッドシートと週次30分のパスで始めるには十分です。方法論は私の[ChatGPT対Google引用テスト](/chatgpt-search-vs-google-50-term-test/)を反映していますが、一度きりではなく継続的に実行します。 ## ダッシュボードを構築する: 4つの数字、週次 私は指標に溺れません。AI検索については4つを見て、週次でレビューします: 1. **AIリファラルセッション** — リファラーセグメントからの数えられるクリック。絶対値ではなく傾向。 2. **引用カバレッジ** — 3つのエンジン全体で引用されている、追跡中クエリの割合。先行指標。 3. **ブランド検索インプレッション** — Search Consoleから、ダークな影響の代理として。 4. **AI由来のコンバージョン** — 小さくても、AIセッションがコンバージョンジャーニーを開始することがあるか。 引用カバレッジが上昇しているのにリファラルセッションが横ばいなら、それは*失敗ではありません*——通常はダークな半分が成長していることを意味し、ブランド検索の数字が後を追うはずです。引用カバレッジが下がっているなら、それはどのトラフィック数字が動くより前に対処すべき早期警告です。これは私がエージェントに適用するのと同じ「先行指標を測定する」規律で、[AIエージェントが本当に機能しているかをどう測定するか](/how-i-measure-whether-an-ai-agent-is-actually-working/)で述べています。 ## 数字をどう使うか 測定は、あなたの行動を変えてこそ役に立ちます。プレイブック: - **気にかけているクエリで引用カバレッジが低い?** それはコンテンツ + [schema](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/)の問題です。ページが存在しないか、抽出向けに構造化されていないか、回答に引き込まれるほど権威的でないかのいずれかです。 - **引用されているがリファラルトラフィックがない?** 想定どおりで問題ありません——AI検索はクリックの仕事ではなくブランドの仕事をしています。クリックを追ってそれを「修正」しないでください。引用されるソースであることに賭けてください。 - **あるエンジンからはリファラルがあるが他からはない?** エンジンはソースで大きく分かれます(ChatGPTとGoogleの間で約40%の重複を測定しました)。一つに引用されても他は手に入りません——各エンジンのカバレッジを別々に取り組んでください。 ## 帰属の誠実さについての注記 持っていない精度を主張したい衝動に抵抗してください。2026年のAI検索測定は帰属ではなく三角測量です。「ChatGPTがあなたにX ドルもたらした」というきれいな数字を売る者は、知り得ることを誇張しています。リファラーは漏れ、最大の効果は設計上ゼロクリックだからです。正しい姿勢——数えられるものを数え、数えられないものは代理指標を見て、傾向で意思決定する。絶対値が信頼できないときでも、傾向は信頼できます。 ## よくある質問 ### GA4でChatGPTやPerplexityからのトラフィックを見るには? AIエンジンのドメイン——chatgpt.com、chat.openai.com、perplexity.ai、claude.ai、gemini.google.com、copilot.microsoft.com——をセッションソースとして一致させるチャネル/セグメントを構築します。これはクリックスルーのリファラルを捕捉しますが、一部は「ダイレクト」に剥がされるため、数を床として扱ってください。 ### AI検索のリファラルトラフィックがなぜこんなに少ないのか? AI検索はほとんどがゼロクリックだからです——エンジンはページ上で答え、少数だけがクリックして進みます。低いリファラル数は、しばしばはるかに大きな引用インプレッションと同時に起こります。リファラルが見逃す部分を見るには、引用とブランド検索の上昇を測定してください。 ### AI検索の最良の先行指標は? 引用カバレッジです——ChatGPT、Perplexity、Claude全体で引用されている、ビジネスに重要な追跡中クエリの割合。トラフィックやブランドの上昇より先に動くので、GEO作業が効いているかを早期に教えてくれます。 ### AI検索から正確な収益帰属を得られるか? いいえ、2026年には信頼できる形では得られません。リファラーはダイレクトに漏れ、影響の大半は設計上ゼロクリックです。AI検索測定は三角測量として扱ってください——クリックを数え、ブランド検索とダイレクトトラフィックの代理指標を見て、偽りの精度を持つドル額ではなく傾向で意思決定してください。 --- ## マルチエージェント・オーケストレーションのパターン:キュー、状態、ハンドオフ Source: https://alejandrorioja.com/ja/multi-agent-orchestration-patterns-queues-state-handoffs/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: 信頼できるマルチエージェントシステムは、巧妙なプロンプトで決まるものではなく、退屈な分散システムの規律で決まる。エージェント間に永続的なキューを置き、状態をモデルの外で保持し、リトライしても二重実行されない冪等なハンドオフを作る。モデルはワーカー、キューはバックボーンだ。 ## 目次 _2026年6月更新。_ **TL;DR:** 信頼できるマルチエージェントシステムは、巧妙なプロンプトで勝ち取るものではなく、退屈な分散システムの規律で勝ち取るものだ。エージェント間に永続的な**キュー**を置き、**状態をモデルの外**で保持し、リトライが二重に動作しないようすべての**ハンドオフを冪等**にする。モデルはワーカー、キューはバックボーンだ。この3つを正しく押さえれば、オーケストレーションは怖いものではなくなる。 **オペレーターの視点:** 私の100以上あるエージェントのほとんどは単一ステップだ。そうでないもの — 分類し、次にエンリッチし、次にアクションするパイプライン — が信頼できるようになったのは、「プロンプトチェーン」と考えるのをやめ、「LLMワーカーを持つジョブキュー」と考え始めてからだった。これはアーキテクチャであって、プロンプトエンジニアリングではない。 「マルチエージェント」というと、エージェント同士が会話するように聞こえる。実際には、信頼できる版はその逆だ。エージェントは直接やり取りなど一切しない。キューにメッセージを置き、キューから仕事を拾い、オーケストレーションはその間の配管に宿る。本番で持ちこたえるパターンを紹介する。 ## パターン1:すべてのエージェントの間に永続的なキューを置く 最初の本能は、エージェントAの中からエージェントBを直接呼び出すことだ。やめておこう。直接呼び出しは両者を結合する。Bが遅ければAはブロックされ、Bが失敗すればAの仕事は失われ、BをスケールしたくてもAに手を入れずにはできない。 代わりに、Aは自分の仕事を終えてBのために**メッセージをキューに入れる**。Bは独立したワーカーで、自分のペースでキューを排出する。 ```typescript // エージェントAが終了し、キュー経由でハンドオフする — Bへの直接呼び出しはない await env.ENRICH_QUEUE.send({ traceId, type: "enrich", payload: classifierResult, }); // Aのジョブは完了。Bが独立してこれを拾う。 ``` Cloudflareでは、まさにこのためにWorkers Queuesを使っている — [私が使うエージェントスタック](/the-agent-stack-i-use-to-run-30-production-agents-no-python/)の背後にあるのと同じプリミティブだ。キューは4つのものを無料で与えてくれる。**バッファリング**(Bがダウンしていても仕事を失わない)、**リトライ**(失敗したメッセージは再配信される)、**バックプレッシャー**(急増はクラッシュせずキューに溜まる)、**疎結合**(Aに手を入れずにBをスケールまたは再デプロイできる)。これらはどれも、さもなければ自前で作って間違える羽目になるものだ。 ## パターン2:状態は常にモデルの外で保持する 最も一般的なマルチエージェントのバグは、モデルがステップ間で何かを覚えていると思い込むことだ。覚えていない。モデルの各呼び出しはステートレスで、唯一の記憶はプロンプトに入れたものだけだ。だから「このジョブがパイプラインのどこにいるか」の信頼できる情報源は、会話ではなくデータベースに宿らなければならない。 私は、すべてのエージェントが読み書きする単一のジョブレコードを保持する。 ```typescript interface JobState { traceId: string; stage: "classified" | "enriched" | "acted" | "done" | "failed"; data: Record; attempts: number; updatedAt: number; } ``` 各エージェントは同じループを回す。ジョブの状態を**読み**、自分の仕事をし、新しい状態を**書き**、次のステージをキューに入れる。モデルは状態を保持せず、関連する切片を入力として受け取り、結果を返す。これがシステムを再起動可能にする。ワーカーがジョブの途中で死んでも、状態レコードは物事がどこにあったかを正確に示し続け、再配信されたキューメッセージがそこから引き継ぐ。デバッグも扱いやすくなる。状態テーブルがすべてのジョブの旅路をクエリ可能な記録として残すからだ — [エージェントが本当に機能しているかをどう測るか](/how-i-measure-whether-an-ai-agent-is-actually-working/)と同じ計測のマインドセットだ。 ## パターン3:すべてのハンドオフを冪等にする キューは*少なくとも1回*の配信を保証するのであって、ちょうど1回ではない。つまりメッセージは2回配信されうる — ネットワークの乱れ、リトライ、再デプロイ。エージェントのアクションが冪等でなければ、二重配信は二重実行する。確認メールが2通、予約が2件、課金が2回。これはオーケストレーションのバグの中で最もたちが悪い種類で、チームが本番で発見するものだ。 修正方法は、キーを使ってアクションを冪等にすることだ。 ```typescript async function handleEnrich(msg: QueueMessage, env: Env) { const job = await getJob(env, msg.traceId); if (job.stage !== "classified") { // このステージをすでに通過済み — これは重複配信。スキップする。 return; } const result = await enrich(job.data); await advanceJob(env, msg.traceId, "enriched", result); await env.ACT_QUEUE.send({ traceId: msg.traceId, type: "act" }); } ``` ステージチェックによって、操作は2回実行しても安全になる。2回目の配信はジョブがすでに進んでいるのを見て何もしない。外部の副作用(メール送信、カード課金)については、下流のAPIに冪等性キーを渡し、*そちらでも*重複排除させる。すべてのメッセージは2回配信されると想定し、それが無害になるよう設計しよう — いずれ必ずそうなるからだ。 ## パターン4:オーケストレーター対コレオグラフィー — 意図的に選ぶ フローを配線する方法は2つあり、正しい選択は複雑さによる。 **コレオグラフィー**(私のデフォルト):各エージェントは次のステップだけを知り、それをキューに入れる。フローはチェーンから創発する。シンプルで分散的、拡張しやすい — キューを挿入するだけでステージを追加できる。欠点は、フロー全体を記述する単一の場所がないため、複雑なパイプラインは見通しが悪くなりうることだ。 **オーケストレーション**(中央コーディネーター):1つのオーケストレーターがフローを所有し、各エージェントを順に呼び出し、結果に基づいて次を決める。フロー全体が読みやすい1か所に宿り、分岐ロジックは明示的だ。代償は、それ自体が永続的でなければならない中央コンポーネントだ — オーケストレーター自身の状態が外部化されていなければ(パターン2)、それが単一障害点になる。 私のルール:**分岐が複雑になるまではコレオグラフィー、その後は永続的なオーケストレーター。** 線形の3ステージのパイプラインはコレオグラフィーだ。条件付きルーティング、並列のファンアウト、ジョインを持つフローには、クラッシュ後に再開できるよう状態がデータベースに宿るオーケストレーターが必要だ。 ## パターン5:断片を失わずにファンアウト・ファンイン 1つのジョブがN個の並列サブタスクを生み(50レコードをエンリッチ、20文書を要約)、続行前にそのすべてを待つ必要があるとき、**ジョイン**が必要だ。コツはジョブ状態のカウンターだ。 1. 親はN個の子メッセージをキューに入れ、ジョブレコードに `expected: N, completed: 0` を書く。 2. 各子は自分の仕事をし、`completed` を**アトミックにインクリメント**する。 3. `completed` を `expected` と等しくまで押し上げた子が、次のステージをキューに入れる。 このアトミックなインクリメントが要だ — これがないと、同時に終わる2つの子が両方とも自分は最後ではないと思い込み、ジョインは決して発火しない。データストアがアトミックにインクリメントできるカウンター、またはトランザクションを使う。このパターンにより、パイプラインの高コストな中間部分を並列化しながら(多くの場合Haikuで安く済む仕事 — [HaikuとSonnetのコスト計算](/ai-agent-cost-math-when-haiku-beats-sonnet)を参照)、最後にクリーンなジョインを保てる。 ## 私が省くもの これらのどれをやるにも、重量級のエージェントフレームワークは要らない。キュー、状態テーブル、冪等性キーは、どのプラットフォームにもすでにあるプリミティブだ。キューが無料でくれる機能を得るために手の込んだマルチエージェントフレームワークに手を伸ばし、置き換えた配管よりデバッグの難しいブラックボックスを抱え込むチームを見てきた。退屈なプリミティブから始めよう。フレームワークに手を伸ばすのは、それが解決する具体的な痛みを感じたときだけにしよう。 まとめ:エージェントはステートレスなワーカー、キューは永続的なバックボーン、状態はデータベースに宿り、すべてのハンドオフは2回実行しても安全。これがすべてだ。 ## よくある質問 ### エージェントは互いを直接呼び出すべきか、それともキューを経由すべきか? キューを経由する。直接呼び出しはエージェントを結合する — 一方の失敗や遅延が他方に伝播し、独立してスケールや再デプロイができない。永続的なキューは、バッファリング、リトライ、バックプレッシャー、疎結合を無料で与えてくれる。 ### マルチエージェントの状態はどこに宿るべきか? モデルの外、データベースの中に、各エージェントが読み書きするジョブレコードとして。モデルの呼び出しはステートレスなので、パイプラインの進捗の信頼できる情報源は外部でなければならない — それがクラッシュ後にシステムを再起動可能にする。 ### 同じジョブに対してエージェントが二重に動作するのをどう防ぐか? ハンドオフを冪等にする。アクションの前にジョブのステージをチェックし、すでに進んでいれば何もせず、外部APIには冪等性キーを渡す。キューは少なくとも1回配信するので、すべてのメッセージが2回到着しうると想定し、重複が無害になるよう設計しよう。 ### マルチエージェントフレームワークは必要か? たいていは不要だ。永続的なキュー、状態テーブル、冪等性キーがあれば、プラットフォームがすでに提供するプリミティブで本番のニーズの大半をカバーできる。フレームワークを採用するのは、それが固有に解決する具体的な問題にぶつかったときだけにし、デフォルトでは採用しない。 --- ## 恐れずにAIエージェントを出荷するために使う評価ハーネス Source: https://alejandrorioja.com/ja/the-eval-harness-i-use-to-ship-ai-agents/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: 恐れずにエージェントを出荷できるのは、たった一つのもの——評価ハーネスのおかげだ。採点済みのテストケースを固定した集合を、自動でスコアリングし(アサーションとLLMジャッジ)、すべてのプロンプトやモデルの変更前に実行する。スコアが保たれれば出荷する。テストセットは実際の本番障害から構築する。 ## 目次 _2026年6月更新。_ **TL;DR:** 稼働中のエージェントでプロンプトを変えたりモデルを差し替えたりしても息を呑まずに済む理由は、たった一つ——**評価ハーネス**だ。採点済みのテストケースを固定した集合を、自動でスコアリングする——書ける場所には厳格なアサーションを、書けない場所にはLLMジャッジを——そしてすべての変更前に実行する。スコアが保たれれば出荷する。スコアが下がれば出荷しない。テストセットは合成ではない。実際の本番障害から構築するので、すべてのバグが恒久的な回帰テストになる。 **オペレーターの読み:** 100を超えるエージェントを見てきて、自信を持って触れるものと怖くて触れないものの違いは、評価があるかどうかだ。評価ハーネスがなければ、あらゆるプロンプトの微調整は賭けになる。評価ハーネスは「これの方が良いと思う」を「これは測定可能に4ポイント良く、何も壊さなかった」に変える。それが解放のすべてだ。 テストなしにコードを出荷しないだろう。人々は評価なしに絶えずエージェントを出荷し、その後「ほんの小さなプロンプトの微調整」がなぜ本番を壊したのか首をかしげる。評価ハーネスは非決定論的ソフトウェアのためのテストスイートだ。これが私が実際に走らせているものだ。 ## 実際の障害から構築したテストセットから始める ハーネスはそのテストケースの質を超えられず、最良のテストケースは想像ではなく本番から来る。エージェントが現場で失敗するたびに、私は正確な入力を捕捉し(すべての実行をトレースIDとともにログに残す——[本番でエージェントをデバッグする方法](/how-to-debug-an-ai-agent-in-production)を参照)、それを評価ケースに変える。 ```typescript interface EvalCase { id: string; input: AgentInput; // 正確な本番入力 expected?: string; // 正解がある場合のグラウンドトゥルース assertions: Assertion[]; // 通過しなければならない厳格なチェック rubric?: string; // 出力がオープンエンドな場合のLLMジャッジ用 } ``` ここで重要な実践が二つある。**本番から引く**こと。そうすれば評価は、推測したものではなく実際に壊れるものをテストする。そして**幅をカバーする**こと——ハッピーパス、エッジケース、敵対的入力、そして静かな失敗を引き起こす空/不正な入力。よく選ばれた30〜50ケースのテストセットは、500の怠惰なケースよりはるかに多くを捕まえる。すべて同じ簡単なパスをテストする千のケースより、それぞれが実際の失敗モードを表す40ケースの方がいい。 ## まずアサーションで、次にLLMジャッジで採点する すべての出力にモデルによる採点が要るわけではない。私は機能する中で最も安い採点器に手を伸ばす。 構造化されたものすべてには**厳格なアサーション**を。出力は有効なJSONとしてパースできるか?必須フィールドを含むか?抽出された日付は範囲内か?正しい引数で正しいツールを呼んだか?これらは決定論的で、無料で、曖昧さがない——書けるだけ書こう。 ```typescript const assertions: Assertion[] = [ (out) => isValidJSON(out), (out) => parse(out).category in ALLOWED_CATEGORIES, (out) => parse(out).confidence >= 0 && parse(out).confidence <= 1, ]; ``` オープンエンドな残りには**LLMジャッジ**を——トーン、有用性、「これは本当に質問に答えたか」。ここではモデルに入力、出力、ルーブリックを与え、採点を求める。ジャッジを正直に保つルールは二つ。ルーブリックを**具体的**にすること(記述されたアンカー付きの1〜5スケールは「品質を評価せよ」に勝る)、そして**強いモデルをジャッジに使う**こと——判定は推論タスクなので、ここはエージェント自体が[コスト計算](/ai-agent-cost-math-when-haiku-beats-sonnet)に従ってHaikuで動いていても、私が喜んでSonnetに支払う場面だ。曖昧なルーブリックや弱いジャッジは、信号に見えるノイズを与える。 ## すべての変更前にハーネスを走らせる ハーネスは一つの問いに答えるために存在する。*この変更はエージェントを良くしたか悪くしたか?* だから私はすべてのプロンプト編集、モデル差し替え、ツール変更の前にそれを走らせる。 ```bash # main上のベースライン npm run eval -- --suite=booking-agent > baseline.json # 変更を加え、再実行する npm run eval -- --suite=booking-agent > candidate.json # 比較する npm run eval:diff baseline.json candidate.json ``` 差分は集計スコア、ケースごとの合否、そして——決定的に——**どの特定ケースが回帰したか**を示す。三つのケースが静かに壊れる一方で集計が上昇するのは改善ではない。それは私が見て承認したいトレードオフであり、こっそり通り抜けるものではない。ケースごとの差分を見守ることが、「一つ直して二つ壊す」——人々を自分のプロンプトに怯えさせる失敗モード——を避ける方法だ。 ## 回帰ゲートを設定し、ブロックさせる ハーネスを信頼したら、それをゲートとして本番への経路に組み込む。私のルールは率直だ。**スコアをベースラインの閾値より下げる変更は出荷しない。** 「後で見ておく」ではない——失敗したCIテストと同様にブロックされる。 ```typescript const PASS_THRESHOLD = 0.90; // 90%のケースが通過しなければならない if (candidate.passRate < PASS_THRESHOLD || candidate.passRate < baseline.passRate) { throw new Error(`Eval regression: ${candidate.passRate} < ${baseline.passRate}`); } ``` これが評価を「あれば良いもの」から、速く動けるようにするものへと変える。ゲートこそが「恐れずに出荷する」を文字通り真にする。悪い変更の最悪のケースは赤い評価実行であって、本番インシデントではない。そしてテストセットは何かが壊れるたびに成長するので、ゲートは時とともに自ら厳しく、より保護的になっていく。 ## 採点における非決定論を考慮する 人々がつまずく微妙な点。同じ入力でも実行ごとに異なるスコアになりうる。モデルが異なるサンプリングをするからだ。各ケースを一度だけ実行すると、幻の回帰が見える——「壊れた」ケースが実はサンプリングノイズにすぎない。 緩和策が二つ。分散を縮めるために評価を**`temperature: 0`**で実行する(完全には消えない)。そしてちらつきを見たケースは、単一の合否ではなく、**N回実行して合格率を取る**。9/10通過するケースは、両方とも緑の単一実行を示しうるとしても、5/10通過するケースより状態が良い。これは[断続的な失敗をデバッグする](/how-to-debug-an-ai-agent-in-production)ときに使うのと同じ、逸話より物量の原則だ——一度の実行は意見、五十回の実行はデータだ。 ## 本番モニタリングでループを閉じる 評価ハーネスは既知のケースに対してテストする。本番は未知のケースを投げてくる。だからループはこうだ。稼働中の挙動をモニタリングし、新しい失敗モードを捕まえ、それを評価ケースに変え、修正する。すると今やそれは恒久的に守られる。モニタリング側——稼働トラフィックでの成功率、出力の妥当性、実行ごとのコストを追跡すること——は[AIエージェントが本当に機能しているかをどう測るか](/how-i-measure-whether-an-ai-agent-is-actually-working/)で扱っている。評価とモニタリングは同じシステムの二つの半分だ。モニタリングがバグを見つけ、評価がそれが死んだままであることを保証する。 そのフィードバックループこそが本当のプロダクトだ。単一の評価セットはどれも古びる。だが、すべての本番障害を恒久的なテストに変える*プロセス*は毎週強くなる。こうしてエージェントは「触るのが怖い」から、金曜の午後にひるまずリファクタリングするものへと変わる。 ## よくある質問 ### AIエージェントの評価セットには何が入るのか? 実際の本番入力を採点済みケースに変えたもの——ハッピーパス、エッジケース、敵対的入力と不正な入力——それぞれに厳格なアサーションを、オープンエンドな出力にはLLMジャッジのルーブリックを添える。実際の障害から引いた30〜50ケースは、すべて簡単なパスをテストする何百もの合成ケースに勝る。 ### エージェントの出力の採点にLLMを使うべきか? 出力が構造化されている場所では(有効なJSON、正しいフィールド、正しいツール呼び出し)どこでも厳格なアサーションを使う——無料で決定論的だ。トーンや有用性のようなオープンエンドな性質には、具体的なルーブリックと強いジャッジモデルを伴うLLMジャッジを取っておく。そうすればノイズではなく信号が得られる。 ### プロンプト変更が静かに本番を壊すのをどう止めるか? すべての変更前に評価ハーネスを走らせ、ベースラインと差分を取り、集計スコアだけでなくケースごとの回帰を見守る。そして結果でデプロイをゲートし、ベースラインの閾値を下回る変更は失敗したテストのようにブロックする。 ### 評価における非決定論をどう扱うか? 分散を減らすために温度0で実行し、ちらつくケースは複数回実行して、単一実行ではなく合格率で採点する。10回中9回通過するケースは、単一実行で両方とも緑を示すとしても、10回中5回通過するケースより健全だ。 --- ## AIエージェントでニュースレターを自動化する方法 Source: https://alejandrorioja.com/ja/how-to-automate-your-newsletter-with-an-ai-agent/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents, Growth TL;DR: Claudeエージェントがコンテンツキューを読み取り、その週の最も強い切り口を選び、私の声でニュースレターを下書きし、エンゲージメント層別にリストをセグメント化し、Kit API経由で送信をスケジュールします——私がエディタを開かずに。レンダリングされたプレビューを確認して承認ボタンを押すだけです。難しいクリエイティブな作業は私のもの。機械的な実行はエージェントのものです。 ## 目次 _2026年6月更新。_ **TL;DR:** Claudeエージェントがコンテンツキューを読み取り、その週の最も強い切り口を選び、私の声でニュースレターを下書きし、エンゲージメント層別にリストをセグメント化し、Kit API経由で送信をスケジュールします——私がエディタを開かずに。レンダリングされたプレビューを確認して承認ボタンを押すだけです。難しいクリエイティブな作業は私のもの。機械的な実行はエージェントのものです。 **[オペレーターの視点]** 一貫して送信されるニュースレターは、「より良い」が霊感が湧いたときだけ発行されるものに勝ります。制約はアイデアではなく、実行のオーバーヘッドでした。アイデアはあった。毎週それをフォーマット、スケジュール、セグメント化する帯域幅がなかっただけです。エージェントがそのギャップを埋めました。 ## ほとんどのニュースレターワークフローにおける本当のボトルネック ほとんどのニュースレター自動化のアドバイスは間違ったことに焦点を当てています:ウェルカムシーケンス、オートメーション、タギングロジック。それらは問題ありませんが、毎週のコンテンツ作成問題を解決しません。 本当の妨げはこれです:言いたいことはわかっている。しかし座ってフォーマットし、件名のバリエーションを書き、適切なセグメントを選び、適切なタイミングでスケジュールすることが週に2〜3時間のコンテキストスイッチングを要します。52週で掛けると、ニュースレターを*送信*するだけに丸々1週間を費やしたことになります。 エージェントは「今週の切り口がわかった」の後のすべてのステップを処理します。 ## 使用しているスタック - **[Kit](/recommends/convertkit)**(旧ConvertKit)——メールプラットフォーム。優れたAPI、確実な購読者タグ付け、クリーンな分析。エージェントフレンドリーなAPIが決め手でした。 - **Claude (Anthropic SDK)**——生成レイヤー - **Cloudflare Workers**——スケジュールトリガー(毎週火曜日午前8時CTに実行) - **Airtable**——コンテンツキューと承認受信トレイ Kitを使っていなくても、ブロードキャストを作成・スケジュールするREST APIを持つプラットフォームなら同じパターンが機能します。 ## ステップ1:コンテンツキュー エージェントには「何について書くか」の信頼できる情報源が必要です。私のは以下の列を持つ[Airtable](/recommends/airtable)テーブルです: - `Topic`——切り口や質問 - `Status`——Queue / Approved / Sent - `Tier`——すべての購読者向けか、エンゲージメントの高い購読者のみか - `Notes`——制約事項(このトーンは避ける、このリンクを含める、など) 毎週、キューに2〜3個のトピックを追加するのに10分を費やします。それが私のクリエイティブな入力です。残りはエージェントの仕事です。 ## ステップ2:下書きエージェント ```typescript // workers/newsletter-agent/index.ts import Anthropic from "@anthropic-ai/sdk"; import Airtable from "airtable"; const client = new Anthropic(); const VOICE_SYSTEM = `You are writing a weekly newsletter for Alejandro Rioja's subscribers. His audience: founders and operators interested in AI agents, SEO, and growing a one-person business. Voice: direct, first-person, practitioner. No hype, no "exciting times," no excessive bullet lists. Structure every newsletter as: 1. One-sentence hook (the problem or observation) 2. The core insight (3–5 paragraphs, no headers, conversational) 3. One concrete action the reader can take this week 4. A short sign-off (2 sentences max) Subject line: specific, outcome-oriented, under 50 chars. No clickbait. Return JSON: { "subject": "...", "preheader": "...", "body": "..." }`; async function getNextTopic(): Promise<{ id: string; topic: string; notes: string; tier: string }> { const base = new Airtable({ apiKey: process.env.AIRTABLE_API_KEY }).base(process.env.AIRTABLE_BASE_ID!); const records = await base("Newsletter Queue") .select({ filterByFormula: "{Status} = 'Queue'", sort: [{ field: "Created", direction: "asc" }], maxRecords: 1 }) .firstPage(); if (!records.length) throw new Error("Queue is empty. Add topics."); const r = records[0]; return { id: r.id, topic: r.get("Topic") as string, notes: (r.get("Notes") as string) ?? "", tier: (r.get("Tier") as string) ?? "all" }; } async function draftNewsletter(topic: string, notes: string): Promise<{ subject: string; preheader: string; body: string }> { const msg = await client.messages.create({ model: "claude-sonnet-4-6", max_tokens: 2048, system: VOICE_SYSTEM, messages: [{ role: "user", content: `Write this week's newsletter on: "${topic}". Additional notes: ${notes || "none"}` }], }); const text = (msg.content[0] as any).text.replace(/```json\n?/, "").replace(/```/, "").trim(); return JSON.parse(text); } async function scheduleWithKit(draft: { subject: string; preheader: string; body: string }, tier: string): Promise { const segmentId = tier === "engaged" ? process.env.KIT_ENGAGED_SEGMENT_ID : null; const sendAt = new Date(); sendAt.setDate(sendAt.getDate() + ((4 - sendAt.getDay() + 7) % 7)); // next Thursday sendAt.setHours(9, 0, 0, 0); // 9am CT const payload: any = { broadcast: { subject: draft.subject, content: draft.body, description: draft.preheader, send_at: sendAt.toISOString(), email_layout_template: "minimal", }, }; if (segmentId) payload.broadcast.segment_id = segmentId; const res = await fetch("https://api.kit.com/v4/broadcasts", { method: "POST", headers: { "Content-Type": "application/json", "X-Kit-Api-Key": process.env.KIT_API_KEY! }, body: JSON.stringify(payload), }); const data = await res.json(); return data.broadcast?.id ?? ""; } export default { async scheduled(_event: ScheduledEvent, env: Env) { // Inject env vars Object.assign(process.env, env); const { id, topic, notes, tier } = await getNextTopic(); const draft = await draftNewsletter(topic, notes); const broadcastId = await scheduleWithKit(draft, tier); // Mark as Approved in Airtable (not Sent — human reviews the Kit preview before confirm) const base = new Airtable({ apiKey: env.AIRTABLE_API_KEY }).base(env.AIRTABLE_BASE_ID); await base("Newsletter Queue").update(id, { Status: "Approved", KitBroadcastId: broadcastId }); console.log(`Scheduled broadcast ${broadcastId} for topic: ${topic}`); }, }; ``` ## ステップ3:承認ステップ エージェントはKitの下書き状態でブロードキャストを作成し、Airtableレコードを「Approved」としてマークします。Kitがプレビューリンク付きの通知を送ってきます。クリックして読み、問題なければ送信を確認します。変更が必要な場合はKitで直接編集します。 これがエージェントが送信メールで完全に自律的になるのを防ぐゲートです。下書きは約90%の確率で信頼しています。レビューで見つける10%——わずかにずれたトーン、確認したい統計、追加したいリンク——は3分間のレビューの価値があります。 ## エージェントが処理する、二度とやりたくないこと - 件名のバリエーションを書き、最善のものを選ぶ - プレヘッダーテキストをフォーマットする - 適切な送信時間を計算する(私のオーディエンスは木曜の朝に開封する;エージェントはこれを知っている) - トピックの層に基づいて正確にセグメント化する - すべてをAirtableに記録して履歴を保持する ## 私がまだ所有していること *アイデア*。キューのトピックは私のもの。切り口は私のもの。エージェントは明確なブリーフの優れた実行者です。戦略レイヤーではありません。キューに悪いトピックを入れれば、悪いトピックについてうまく書かれたニュースレターが得られます。 また:最初のレビューゲート。すべての送信は配信前に私の目を通します。これは変わりません。 ## オペレーターの結論 ニュースレターの機械的作業——フォーマット、スケジューリング、セグメンテーション——に週1時間以上費やしているなら、自動化すべきです。Kit APIはクリーンで、WorkerのCronトリガーは岩のように堅固で、Claudeの下書き品質は私が第一稿の約90%を変更なしで承認できるほど高いです。Airtableにキューを構築し、Workerを接続して、送信を実行する代わりにアイデアを作ることに戻りましょう。 --- ## 新しいブログ記事を一本も書かずにAI検索でランクインする方法 Source: https://alejandrorioja.com/ja/how-to-rank-in-ai-search-without-writing-a-single-new-blog-post/ Published: 2026-06-06 Updated: 2026-06-06 Tags: GEO, SEO TL;DR: AIエンジンは、質問に直接答え、明確な著者を主張し、検索を容易にする方法で知識を構造化するコンテンツを引用します。既存のブログ記事のほとんどは、書き直しではなく編集によって3つの基準を満たすよう改修できます。プレイブック:直接的なTL;DRを追加し、エンティティシグナルを強化し、FAQスキーマを追加し、llms.txtに提出する。新しいコンテンツは任意;再構成は必須。 ## 目次 _2026年6月更新。_ **TL;DR:** AIエンジンは、質問に直接答え、明確な著者を主張し、検索を容易にする方法で知識を構造化するコンテンツを引用します。既存のブログ記事のほとんどは、書き直しではなく編集によって3つの基準を満たすよう改修できます。プレイブック:直接的なTL;DRを追加し、エンティティシグナルを強化し、FAQスキーマを追加し、llms.txtに提出する。新しいコンテンツは任意;再構成は必須。 **【オペレーターの視点】** GEO向けの新記事を1本書く前に、341の既存記事にこのプロセスを適用しました。ChatGPTとPerplexityでの引用が増加しました。新コンテンツが成果を加速させましたが、既存コンテンツの監査が出発点であり、予想より早く成果が出ました。 ## なぜAIエンジンが既存コンテンツを引用しないのか 何か新しいものを書く前に問いかけてください:なぜすでに持っているものが引用されていないのか? 答えがほぼ「コンテンツが存在しない」ということはありません。たいていは以下のいずれかです: 1. **上部に直接的な答えがない** — 記事が6段落目に答えを埋めている 2. **著者シグナルが弱い** — 明確な著者エンティティがない、コンテンツに資格がない 3. **構造的なノイズ** — 長い導入部、無関係なセクション、明確な見出し階層がない 4. **機械可読なQ&Aがない** — AIエンジンは構造化された質問-回答ペアを好む;ほとんどのブログ記事はそれを持っていない 5. **どのAI可読インデックスにも含まれていない** — llms.txtがなく、クローラーが見つけるサイトマップもない 5つすべて既存コンテンツで修正可能です。いずれも新しい記事を必要としません。 ## 4ステップの改修プロセス ### ステップ1:最初の100語以内に直接的なTL;DRを追加 AIエンジンはあなたが斜め読みするときに行うことに類似したことをします — より深く進む前に直接的な答えを探します。あなたの記事が物語、質問、またはコンテキスト設定で始まる場合、モデルは実際の答えを見つけるほど遠くまで読まないかもしれません。 修正:最初の100語以内に**TL;DR**ブロックを追加します。形式:結論 → 理由 → 制約または注意事項。2〜4文。余分な言葉は不要。 改前の例: > *なぜ一部の企業がGoogleの検索結果を支配しているように見えるのか不思議に思ったことはありませんか?この記事では、上位ランクのサイトが使用する戦略を探ります...* 改後の例: > **TL;DR:** 2026年にローカルSEOの針を動かす3つのこと:Googleビジネスプロフィールの完全性、ディレクトリ全体の引用の一貫性、NAPデータの構造化スキーマ。「毎日投稿する」や「100件のレビューを素早く獲得する」などの戦術はこれら3つに対して二次的です。上限はGBPの精度です — まずそれを修正してください。 書き直しは長くありません。ただ前に置かれているだけです。 ### ステップ2:エンティティシグナルを強化する AIエンジンはナレッジグラフを構築します。誰がこれを書いたか、何についてのものか、著者はこのトピックで信頼できるか、を知りたいのです。 著者エンティティについて:すべての記事からAboutページがリンクされ、著者スキーマにLinkedInとTwitterへの`sameAs`リンクが含まれ、各記事の著者プロフィールが具体的な資格を述べていることを確認してください(「マーケティングプロフェッショナル」ではなく「3つのSaaS企業のSEOを0から月間100K訪問者に運営した」)。 トピックエンティティについて:オーディエンスが検索する正確な用語を使用してください。「GEO」(ジェネレーティブエンジン最適化)をカバーしている場合、略語だけでなくどこかで「ジェネレーティブエンジン最適化」と言ってください。モデルはコンテンツを分類するために用語の共起を使用します。 ### ステップ3:質問に答えるすべての記事にFAQスキーマを追加 FAQPageスキーマはGEO引用のために最も高い効果を持つスキーマタイプです。なぜなら、モデルが直接解析できる形式で質問と回答を明示的にマッピングするからです。 記事が暗黙的に答えている3〜5の質問を取り出し、明示的にしてください: ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How long does it take to rank in AI search?", "acceptedAnswer": { "@type": "Answer", "text": "Most sites see initial citation improvements within 4–8 weeks of restructuring existing content for direct answers and adding FAQ schema. Brand-new domains take longer — expect 3–6 months before consistent citations appear." } } ] } ``` これを記事の``またはCMSのスキーマフィールドに追加してください。すべての主要AIエンジンがこれをクロールして解析します。 ### ステップ4:llms.txtとプラットフォームのAIインデックスに提出する `llms.txt`は新興の標準です — `yoursite.com/llms.txt`のプレーンテキストファイルで、AIクローラーにどのコンテンツが高品質で、どのように優先順位を付けるかを伝えます。LLM向けの`robots.txt`に類似しています。 基本的なllms.txt: ``` # llms.txt # alejandrorioja.com — AI agents and GEO for operators ## Priority content - /blog/geo-for-local-business (definitive guide, updated monthly) - /blog/schema-markup-for-ai-engines (technical reference) - /blog/how-to-get-cited-by-chatgpt (step-by-step) ## Author Alejandro Rioja — operator, AI agent builder, GEO practitioner. LinkedIn: https://linkedin.com/in/alejandrorioja ``` `lastmod`タイムスタンプを含む清潔なサイトマップと組み合わせてください。AIクローラーは古く見えるコンテンツの優先順位を下げます。 ## どの記事を改修するか優先順位をつける方法 すべての記事が改修する価値があるわけではありません。最初のパスを以下に集中させてください: 1. **質問形式のキーワードで既にページ1にランクしている記事** — これらは引用されることに最も近い;構造修正が必要なだけ 2. **あなたが検証可能な信頼性を持つトピックに関する記事** — AIエンジンは著者を重く評価する;あなたの資格が関連する記事はエンティティシグナルから引用の向上を得る 3. **質問に直接答える記事vs情報を提供する記事** — 「Xの方法」と「Xとは何か」はリスト記事や意見記事よりも改修効果が高い Search Consoleデータを使用してください:質問形式のクエリ(how、what、why、best way to)でフィルタリングします。これらのクエリで5〜15位にランクしている記事が最も良い改修候補です — 関連性はあるが、引用されるほどトップに近くない。 ## 多くの人が犯す間違い 既存のアーカイブを改修する前に、AI検索向けに最適化された新しい記事を書いてしまいます。新しいコンテンツは役立ちますが、既存の記事には年齢、バックリンク、クロール履歴という強みがあります。構造が良好な3年前の記事は、同じトピックの新しい記事を何ヶ月も上回ります。 まず改修を行ってください。真のギャップがある場所 — 既存の記事がまったく答えていない質問 — に新しいコンテンツを書いてください。それが新しいものが古いものより良い時です。 ## オペレーターの最終結論 20以上の既存ブログ記事がある場合、GEO作業はコンテンツカレンダーではなく、監査と改修から始まります。TL;DRを追加し、エンティティシグナルを強化し、FAQスキーマを追加し、llms.txtに提出してください。何か新しいものを書く前に、トップ20の記事でそれを行ってください。数ヶ月ではなく数週間で引用の改善が見られるでしょう — そして新しいコンテンツが実際に針を動かすかどうかを測定するためのより清潔なベースラインを持てます。 --- ## Facebook広告を運用するClaudeスキルを作った——コードを公開する Source: https://alejandrorioja.com/ja/i-built-a-claude-skill-that-runs-my-facebook-ads-heres-the-code/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents TL;DR: Graph API経由でMeta Adsアカウントを読み取り、パフォーマンス不足の広告を特定し、ブランドボイスで広告コピーを書き直し、広告マネージャーを触ることなく新しい広告セットを作成するClaudeスキルを構築した。全体で300行未満のTypeScript。ROIは即座だった:週次の広告管理時間を約3時間から約20分に短縮した。 ## 目次 _2026年6月更新。_ **TL;DR:** Graph API経由でMeta Adsアカウントを読み取り、パフォーマンス不足の広告を特定し、ブランドボイスで広告コピーを書き直し、広告マネージャーを触ることなく新しい広告セットを作成するClaudeスキルを構築した。全体で300行未満のTypeScript。ROIは即座だった:週次の広告管理時間を約3時間から約20分に短縮した。 **[オペレーターの視点]** PicklelandとコンサルティングブランドのためにFacebook広告を運用している。2つのアカウント、異なるオーディエンス、常に続くクリエイティブ疲弊。毎週日曜の午後を広告マネージャーの中で過ごし、モデルがやるべきことをやっていた。だから自動化した。 ## Facebook広告の手動管理をやめた理由 Facebook広告を運用する実際の作業は、3つの仕事に分けられる: 1. **モニタリング** — どの広告セットがお金を燃やしているか、稼いでいるかを確認する 2. **診断** — なぜパフォーマンスが低いかを突き止める(クリエイティブ疲弊?ターゲティングの問題?ランディングページ?) 3. **イテレーション** — 新しいコピーを書き、新しい広告セットを作成し、予算を調整する 仕事1は機械的だ。仕事3もほぼ機械的だ(ボイスの制約がある)。仕事2は判断が必要——人間がループに入ることで価値が生まれる唯一の部分だ。 Claudeスキルは1と3を担える。私は仕事2の出力を確認してから公開する。これが落ち着いたアーキテクチャだ。 ## Meta Graph APIのセットアップ(ここが面倒な部分) コードの前に:Meta Businessアカウント、システムユーザー、恒久的なアクセストークンが必要だ。FacebookのデベロッパーポータルはUIが悪いが、手順はこうだ: 1. developers.facebook.comで**Meta App**を作成する(タイプ:Business) 2. **Marketing API**プロダクトを追加する 3. ビジネスポートフォリオ → 設定 → ユーザー → システムユーザーで、システムユーザーを作成し、広告アカウントへの`ADVERTISER`ロールを付与する 4. 以下の権限を持つトークンを生成する:`ads_read`、`ads_management`、`business_management` トークンを`META_ACCESS_TOKEN`として、広告アカウントID(形式:`act_XXXXXXXX`)を`META_AD_ACCOUNT_ID`として`.env`に保存する。 ## スキルのファイル構造 ``` .claude/skills/fb-ads/ SKILL.md ← Claudeが読む指示 index.ts ← 実際のツール実装 types.ts ← 共有型 ``` `SKILL.md`はClaudeにスキルをいつどのように使うかを伝える。私のものはこうだ: ```markdown # Facebook Ads Manager Skill Use this skill when the user says "check my ads", "run ads report", "pause underperformers", or "write new ad copy". Never run this without explicit user instruction — it touches live ad spend. ## What it can do - Pull performance data for all active ad sets (last 7 or 30 days) - Flag ad sets with ROAS < 1.5 or CTR < 0.8% as underperformers - Rewrite ad copy for flagged creatives in Ale's voice - Create new ad sets with revised copy (PAUSED by default — you approve before activating) ## What it will NOT do - Change budgets on live ad sets without explicit confirmation - Activate new ad sets automatically - Delete anything ``` 「自動的に有効化しない」という制約は譲れない。このスキルは一時停止状態でものを作る。確認して手動で有効化する。ライブの広告費に触れるものはすべて、人間のチェックポイントが必要だ。 ## TypeScriptのコア実装 (コードブロックは英語のまま——周囲のテキストのみ翻訳する。) ## 日々の使い方 スキルはClaude Code(私の日常ツール)から呼び出す。典型的な月曜朝のセッション: ``` > check my ads from the last 7 days ``` Claudeが`runAdsReport(7)`を実行し、結果を表形式にフォーマットし、低パフォーマーにフラグを立て、リライトが必要かを尋ねてくる。「はい」と答える。新しいコピーを生成し、両バージョンを並べて見せ、新しいクリエイティブで一時停止状態の広告セットを作成する。広告マネージャーで確認し、気に入ったものを有効化し、ダメなものをアーカイブする。 合計時間:20分。日曜午後を広告マネージャーで過ごすことはもうない。 ## これが代替できないもの プロダクトマーケットフィットの問題がコピーの問題に偽装しているかどうかを、スキルは教えてくれない。ROAS全体が悪い場合、それはファネルや提供物の問題であり、見出しの問題ではない。Claudeは壊れたファネルの上でコピーを忠実に書き直す——しかしリライトではファネルは救えない。 診断ステップはまだ私のものだ。レポートを読み、ファネルデータを確認し、クリエイティブをイテレーションするのか、上流の何かを解決するのかを判断する。エージェントはその判断*以外*のすべてにおいて速い。 ## オペレーターの結論 手動で広告を管理し、週に2回以上広告マネージャーを触っているなら、スクリプトがやるべき作業をやっていることになる。Graph APIはよくドキュメント化されており、Metaのアクセス許可フローは面倒だが一度きりの設定だ。午後一つでスキルを構築できる。取り戻した時間の見返りは最初の週に現れる。 --- ## ビジネス運営に実際使っているAIツール5選(2026年) Source: https://alejandrorioja.com/ja/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents, Growth TL;DR: 5つのツール:Claude(オペレーターレイヤー+コーディング)、Cursor(TypeScript開発)、Airtable(全エージェントのデータ基盤)、Kit(ニュースレター+メール自動化)、Cloudflare Workers(エージェントホスティング)。試した他のツールはすべてこれらのいずれかに置き換えられるか、完全に削除されました。今日ゼロから始めるとしたら、これが私が再構築するスタックです。 ## 目次 _2026年6月更新。_ **TL;DR:** 5つのツール:Claude(オペレーターレイヤー+コーディング)、Cursor(TypeScript開発)、[Airtable](/recommends/airtable)(全エージェントのデータ基盤)、[Kit](/recommends/convertkit)(ニュースレター+メール自動化)、Cloudflare Workers(エージェントホスティング)。試した他のツールはすべてこれらのいずれかに置き換えられるか、完全に削除されました。今日ゼロから始めるとしたら、これが私が再構築するスタックです。 **【オペレーターの視点】** 私は2つのビジネスを運営しています:個人AIコンサルティングブランド(alejandrorioja.com)と、テキサス州プフルーガービルにあるピックルボール施設Picklelandです。異なるコンテキスト、異なるオーディエンス、異なる運営。この5つのツールが両方を支えています。トレンドだから挙げているのではありません。代替品を削除したから挙げています。 ## 1. Claude — オペレーターレイヤー Claude(Claude CodeとAnthropic SDK経由)は、動くもの全てのブレインです。3つのモードで使用しています: **Claude Code**は日常の開発ドライバーです。TypeScriptを書き、エージェントを構築し、インフラ問題をデバッグし、コンテンツを管理する——すべてClaude Codeインターフェースから行います。単なるオートコンプリートではありません。500行のファイルを読み、意図を理解し、私が考えていなかったリファクタリングを提案できるコラボレーターです。 **Anthropic SDK**は私が構築した全エージェントを動かしています。ニュースレターエージェント、FacebookアドスキルClaude、コンテンツパイプライン、OGカードジェネレーター——バックエンドはすべてClaudeです。モデルの品質が十分に高いため、初稿を約85%の時間で信頼しています。 **Claudeのボイスとブランド**判断は過小評価されています。私らしく聞こえる必要があるものを書くとき、Claude+詳細なシステムプロンプトがテストした他のすべてのモデルを上回ることを発見しました。コツは具体的で意見のあるシステムプロンプトです——「カジュアルなトーンで書く」ではなく、「Alejandroのように書く:直接的、実践者、誇張なし、番号付き、一人称、率直な注意点付き。」 Claude Maxを利用しています。最も使用頻度の高いサブスクリプションで、ROIは比較になりません。 ## 2. Cursor — TypeScriptが書かれる場所 CursorはIDEです。約1年前にVS Codeから切り替えて、振り返ることがありません。 タブ補完は、コードの書き方を本当に変えるほど速い——より高い視点で考え、Cursorに構文的なボイラープレートを任せます。AI提案のdiffビューはクリーンです。マルチファイルコンテキストウィンドウにより、関数の更新を依頼すると呼び出し元も更新してくれます。 アーキテクチャの決定にCursorは使いません。それはまだ紙かClaudeでスケッチします。しかし設計が明確になれば、Cursorは設計から動くTypeScriptへの最速のパスです。 最大のアンロック:Cursor+Claude Codeを並行して使用。高レベルの計画とエージェントオーケストレーションにはClaude Code、実装詳細作業にはCursorを使用します。競合しません——異なる高度をカバーしています。 ## 3. Airtable — データ基盤 私が運営する全AIエージェントは、読み書きする場所が必要です。その場所が[Airtable](/recommends/airtable)です。 両方のビジネスで使用している内容: - **コンテンツキュー** — 進行中の投稿とニュースレタートピック、ステータス追跡付き - **予約レコード** — 予約システムから同期されたPicklelandコート予約 - **アフィリエイトリンクカタログ** — コンテンツエージェントが生成時に読む105以上のスラグとメタデータ - **エージェント監査ログ** — 何が実行され、いつ、何を生産し、エラーがあったか APIはクリーンで高速です。Airtableは高スループット作業負荷向けのデータベースではありませんが、エージェントのサイドテーブル、レビューキュー、人間参加型承認ワークフローには正確に適切なツールです。ビジュアルインターフェースにより、クエリを書かずに任意のテーブルを検査できます。 試した代替案:Notionデータベース。Notion APIは遅く、データモデルはエージェントの読み取りには扱いにくい。エージェント隣接データではAirtableが勝ちます。 ## 4. Kit — ニュースレターとメール自動化 [Kit](/recommends/convertkit)(旧ConvertKit)に切り替えた理由は一つ:APIが実際に良い。 ほとんどのメールプラットフォームはAPIを後付けとして扱います。KitはそれをFirst-classプロダクトとして扱います。ブロードキャストを作成し、送信をスケジュールし、タグでセグメント化し、分析を読む——すべてプログラマティックに。ニュースレターエージェントは私がコンポーザーに触れることなく、これらすべてを行います。 使用しているKit固有の機能: - **Broadcasts API** — エージェントが毎週プログラマティックにスケジュールされたブロードキャストを作成 - **サブスクライバータグ付け** — 行動によってサブスクライバーにタグ付け(最後の5送信を開いた=「エンゲージド」;60日間開いていない=「リスクあり」)、エージェントがそれに応じてセグメントをターゲット - **フォーム+ランディングページ** — クリーン、高速読み込み、ノーコード。これらをプログラマティックに操作しません;ただ機能します。 MailchimpやレガシープラットフォームにいるならKitへの移行は価値があります。MailchimpのAPIはKitが1回の呼び出しで行うことを3回余分な呼び出しで行う必要があります。 ## 5. Cloudflare Workers — エージェントが住む場所 スケジュールされたエージェントはすべてCloudflare Workersで実行されます。主張:グローバルエッジデプロイメント、無料ティアでのゼロコールドスタート、そして実際に機能するcronトリガーシステム。 私のエージェントはサーバーを必要としません。信頼性よく実行され、外部API呼び出しができ、私のスケールでほぼコストゼロのスケジュール関数が必要です。Workersが答えです。 Workersで実行しているもの: - **コンテンツパイプライン** — EN投稿を生成し、12の翻訳に展開し、OGカードを生成 - **ニュースレターエージェント** — 週次送信をドラフトしてスケジュール - **Facebook広告モニター** — パフォーマンスを読み、アンダーパフォーマーにフラグを立て、通知する - **Pickleland稼働率レポーター** — 予約データを読み、毎日サマリーを送信 これらすべての月間総コスト:約$5。これが有料Workersプランです。エージェントはcronスケジュールで信頼性よく実行されています;6ヶ月で1回の障害がありました(Meta側のDNSの問題、私の側ではありません)。 ## 削除したものとその理由 **Zapier** — Workers+各プラットフォームAPIに直接置き換え。Zapierはレイテンシーを追加し、スケールではコストが高く、Workersにはない上限があります。 **ChatGPT** — Claudeのコンテキストウィンドウ、ツール使用、システムプロンプト品質はオペレーターのユースケースでより優れています。クイックウェブ検索のためにChatGPTタブを維持していますが、その上には構築していません。 **Webflow** — サイトをAstro+Cloudflare Pagesに移動。より多くのコントロール、より良いパフォーマンス、スクリプトできるビルドプロセス。 **Grammarly** — ClaudeはGrammarlyが行うすべてをこなし、私の声をよりよく維持します。 ## オペレーターの最終結論 上記5つのツールは最も新しくも最も議論されているものでもありません。2つの異なるビジネスで日常的な本番使用に耐えたものです。スタックに新しいツールを追加する前に聞いてください:これら5つのうちどれがこの仕事をできるか?「すでにその一つができる」という答えがどれほど頻繁に出るか、驚くことでしょう。 --- ## AIエージェントが本番環境で失敗し続ける理由(そして修正方法) Source: https://alejandrorioja.com/ja/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents TL;DR: 本番エージェントの失敗のほとんどは5つの原因から来ます:エッジケースを処理しない脆弱なプロンプト、一時的なAPIエラーのリトライロジックの欠如、何が壊れているか見えない可観測性の欠如、終了条件のないループ暴走、モデルが間違ったものを選ぶほど曖昧なツール定義。すべての5つはモデルやフレームワークを変えなくても修正可能です。 ## 目次 _2026年6月更新。_ **TL;DR:** 本番エージェントの失敗のほとんどは5つの原因から来ます:エッジケースを処理しない脆弱なプロンプト、一時的なAPIエラーのリトライロジックの欠如、何が壊れているか見えない可観測性の欠如、終了条件のないループ暴走、モデルが間違ったものを選ぶほど曖昧なツール定義。すべての5つはモデルやフレームワークを変えなくても修正可能です。 **【オペレーターの視点】** 本番で30以上のエージェントを動かしています。これらの失敗はすべて経験しました。最も時間を費やしたのはエキゾチックなものではありませんでした——対処済みだと思っていた退屈なインフラ失敗でした。 ## 失敗1:エッジケースの入力で壊れる脆弱なプロンプト テストケースで動くプロンプトは、予期しない入力で失敗します。これはモデルの限界ではありません——指示の書き方の問題です。 **症状:** エージェントが無意味な出力を生成する、間違ったツールを呼び出す、またはテストしたものと入力が少し異なるときに不正なJSONを出力する。 **根本原因:** システムプロンプトはハッピーパスのみを説明しています。データが欠落、不正、または曖昧なときに何をすべきかモデルに伝えていません。 **修正:** システムプロンプトに明示的なエッジケース処理を追加する: ``` If the input data is missing a required field, return: { "status": "error", "reason": "missing_field", "field": "" } Do NOT attempt to infer or hallucinate missing values. If you are uncertain which tool to call, call no tool and return: { "status": "clarification_needed", "question": "..." } ``` モデルはエッジケースの明示的な指示を確実に従います。ミスは、ハッピーパスの指示が乱雑なケースを処理するために一般化されると仮定することです。 ## 失敗2:一時的なAPIエラーのリトライロジックなし エージェントが呼び出すすべての外部APIはいつかは失敗します。Claude API、Meta Graph API、データベース——すべて5xxエラーを返したり、タイムアウトしたり、レート制限したりします。エージェントにリトライロジックがない場合、一つの一時的なエラーで全実行が終わります。 **症状:** エージェントの実行が異なるステップでランダムに失敗する。ログは503または429を示し、フォローアップの試みはない。 **修正:** すべての外部呼び出しを指数バックオフリトライでラップする: ```typescript async function withRetry(fn: () => Promise, retries = 3, baseDelayMs = 500): Promise { for (let attempt = 0; attempt <= retries; attempt++) { try { return await fn(); } catch (err: any) { const isTransient = err.status === 429 || err.status >= 500 || err.code === "ECONNRESET"; if (!isTransient || attempt === retries) throw err; const delay = baseDelayMs * Math.pow(2, attempt) + Math.random() * 100; await new Promise((r) => setTimeout(r, delay)); } } throw new Error("unreachable"); } // Usage const result = await withRetry(() => client.messages.create({ ... })); ``` 指数バックオフを持つ3回のリトライは一時的な失敗の約99%を処理します。これをすべての外部呼び出しに追加すれば、ランダムな失敗の半分が消えます。 ## 失敗3:可観測性なし——何が壊れているか見えない これは本番で最も一般的な失敗モードであり、デバッグに最もコストがかかるものです:エージェントが静かに失敗するか間違った出力を生成し、チェーンのどこで何が間違ったかわかりません。 **症状:** 何かがおかしいとわかるが、ステップを特定できない。`console.log`文を追加して手動で再実行して再現しようとする。 **修正:** すべてのステップで構造化ロギング、実行全体をトレースする実行IDを持つ: ```typescript function createLogger(runId: string, agentName: string) { return { step: (step: string, data: object) => console.log(JSON.stringify({ runId, agent: agentName, step, ts: new Date().toISOString(), ...data })), error: (step: string, err: unknown) => console.error(JSON.stringify({ runId, agent: agentName, step, error: String(err), ts: new Date().toISOString() })), }; } const log = createLogger(crypto.randomUUID(), "newsletter-agent"); log.step("fetch_topic", { topicId: topic.id, topic: topic.name }); // ... do work ... log.step("draft_complete", { subject: draft.subject, wordCount: draft.body.split(" ").length }); ``` Cloudflare Workersを使用している場合、これらのログはLogpushまたはWorkers Tailに送られます。ローカルまたはVPSで実行している場合、ログアグリゲーターにパイプします。構造化JSONにより`runId`でフィルタリングして、単一の実行で何が起きたかを正確に確認できます。 ## 失敗4:終了条件のないループ暴走 エージェントループ——モデルがツールを呼び出して条件が満たされるまで反復する——は、その条件が決して満たされないか、モデルが誤って識別すると永遠に実行される可能性があります。 **症状:** エージェントがタイムアウトする前に何百ドものAPIコストを費やす。または進展なく同じツール呼び出しを繰り返し実行する。 **修正:** 常にハードな反復上限と進行チェックを持つ: ```typescript const MAX_ITERATIONS = 10; let iterations = 0; let lastToolCallName = ""; let sameToolCallCount = 0; while (true) { iterations++; if (iterations > MAX_ITERATIONS) { log.error("loop", { reason: "exceeded_max_iterations" }); break; } const response = await client.messages.create({ ... }); // Detect stuck loops: same tool called 3x in a row const toolCall = response.content.find(b => b.type === "tool_use"); if (toolCall?.name === lastToolCallName) { sameToolCallCount++; if (sameToolCallCount >= 3) { log.error("loop", { reason: "stuck_loop", tool: toolCall.name }); break; } } else { sameToolCallCount = 0; lastToolCallName = toolCall?.name ?? ""; } if (response.stop_reason === "end_turn") break; } ``` これは「長く走りすぎた」と「その場で回った」両方の失敗モードを捕まえます。上限はハッピーパスには十分寛大で、爆発半径を制限するのに十分タイトである必要があります。 ## 失敗5:モデルが間違って解決する曖昧なツール定義 モデルに重複した説明を持つ2つのツールを与えると、時々間違ったものを呼び出します。これは`search_database`対`get_record`や`send_email`対`create_draft`などのツールで特に一般的です。 **症状:** モデルは正しいカテゴリのツールを呼び出すが、間違った特定のものを選ぶ。または間違ったコンテキストでツールを呼び出す(読み取りだけが適切な場合に書き込みツールを使用する)。 **修正:** ツールの説明を相互に排他的にし、明示的に「いつ使用しないか」を追加する: ```typescript const tools = [ { name: "get_subscriber", description: "Fetch a single subscriber record by email. Use ONLY when you have a specific email address. Do NOT use for searching or listing subscribers.", input_schema: { ... } }, { name: "search_subscribers", description: "Search subscribers by tag, segment, or status. Use when you need to find subscribers matching a criteria — NOT when you have a specific email address.", input_schema: { ... } } ]; ``` 「Xの場合は使用しない」条項は、ほとんどの人がスキップする部分です。これが最も重要な部分です。モデルは積極的な説明からそれを推論するよりも、明示的な否定的制約に従うのが得意です。 ## もう一つのこと:悪い入力でエージェントをテストする ほとんどのエージェントはクリーンなハッピーパスの入力のみでテストされます。本番環境には汚い入力があります:空の文字列、nullフィールド、Unicodeエッジケース、200を返すが予期しないスキーマのAPIレスポンス。 以下を明示的にテストするテストスイートを追加する: - 空またはnullの入力 - 期待される最大長の入力 - 特殊文字または非ASCIIテキストの入力 - 予期しないレスポンス形式を返す外部API これらのいずれかでエージェントが壊れた場合、本番公開前に修正してください。本番環境はあなたが行ったすべての仮定を見つけます。 ## オペレーターの最終結論 本番でのほとんどのエージェント失敗は、モデルの問題に偽装したインフラの問題です。モデルを切り替える前に、プロンプトにリトライ、構造化ロギング、ループキャップ、明示的なエッジケース処理を追加してください。曖昧なツール定義を修正してください。それから悪い入力でテストしてください。モデルを責める前にそれらすべてをやってください——私の経験では、モデルは通常、変更が必要な最後のものです。 --- ## 15分で初めてのAIエージェントを構築する方法 Source: https://alejandrorioja.com/ja/how-to-build-your-first-ai-agent-in-15-minutes/ Published: 2026-06-02 Updated: 2026-06-02 Tags: AI Agents TL;DR: フレームワークも、講座も、博士号も必要ありません。必要なのはNode.js、Anthropic SDK、そして25行のTypeScriptだけです。このチュートリアルでは、本物の動くエージェント——同じセッション内でCloudflareにデプロイできる構造化コンテンツ要約ツール——を構築します。唯一の前提条件は、無料のAPIキーです。 ## 目次 _2026年6月更新。_ **TL;DR:** フレームワークも、講座も、博士号も必要ありません。必要なのはNode.js、Anthropic SDK、そして25行のTypeScriptだけです。このチュートリアルでは、本物の動くエージェント——同じセッション内でCloudflareにデプロイできる構造化コンテンツ要約ツール——を構築します。唯一の前提条件は、無料のAPIキーです。 **[オペレーターの視点]** AIで自動化したい創業者から最もよく聞くのは「まずもっと学ばなければ」という言葉です。その必要はありません。エージェントのパターンはシンプルで、それを理解する最速の方法は実際に1つ作ってみることです。今日ゼロから始めるとしたら私が取るであろう、まさにその道筋を紹介します。 ## なぜ「AIエージェントを作ろう」系チュートリアルの多くは役に立たないのか それらはPythonを使う(MLエンジニアには適しているが、それ以外の人には摩擦になる)か、LangChainのようなフレームワークの背後に本当のコードを隠すか、実際の業務につなげるには抽象的すぎるものを作るかのいずれかです。 このチュートリアルは、3つの点で異なります。 1. **TypeScriptのみ** — JavaScriptを書いたことがあれば、これに付いてこられます 2. **フレームワークなし** — モデルに触れるすべてのコード行が見えます 3. **役立つ出力** — 顧客メール、レビュー、会議メモに実際に使える構造化要約ツールを構築します ## あなたが構築するもの **コンテンツ要約エージェント**:任意のテキストブロックを貼り付けると、一貫した形式の構造化された要約が返ってきます。HTTPリクエストが1つ入力され、きれいな要約が1つ出力されます。 これを最初のプロジェクトとする理由:このパターン——システムプロンプト + ユーザー入力 → 構造化出力——は、私が運用するすべてのエージェントの基盤です。システムプロンプトを差し替えれば、質問応答ツール、トーン書き換えツール、分類器、下書き生成ツールになります。これを一度学べば、本番のエージェントが実際に行うことの80%を学んだことになります。 ## 前提条件(2分) - **Node.js 18以上** — `node --version`で確認してください。必要であればnodejs.orgからインストールしてください。 - **Anthropic APIキー** — [Claude](/recommends/claude)でサインアップし、コンソールからキーを取得します。無料枠で動作します。 - ターミナルとテキストエディタ。 Dockerなし。仮想環境なし。`pip install`も一切なし。 ## ステップ1:プロジェクトを作成する(2分) ```bash mkdir my-first-agent && cd my-first-agent npm init -y npm install @anthropic-ai/sdk npm install -D tsx typescript ``` エージェントを簡単に実行できるよう、`package.json`にスクリプトを追加します。 ```json { "scripts": { "agent": "tsx agent.ts" } } ``` ## ステップ2:エージェントを書く(5分) `agent.ts`を作成し、これを貼り付けます。 ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY, }); const SYSTEM_PROMPT = `You are a precise content summarizer. When given any block of text, return a structured summary in this exact format: **One-line summary:** **Key points:** - - - **Action item (if any):** Be specific. No filler. Under 150 words total.`; async function summarize(text: string): Promise { const message = await client.messages.create({ model: "claude-haiku-4-5", max_tokens: 512, system: SYSTEM_PROMPT, messages: [{ role: "user", content: text }], }); const block = message.content[0]; if (block.type !== "text") throw new Error("Unexpected response type"); return block.text; } const sample = ` Hey team — following up on the Q2 review meeting. We agreed to push the launch to July 15th instead of June 30th due to the payment integration delay. Marketing needs the new landing page copy by June 20th or we can't start the email campaign. Budget for the launch campaign is confirmed at $8,000. Please confirm receipt. `; const result = await summarize(sample); console.log(result); ``` ## ステップ3:実行する(1分) ```bash ANTHROPIC_API_KEY=sk-ant-... npm run agent ``` 期待される出力: ``` **One-line summary:** Launch pushed to July 15th due to payment delay; landing page copy needed by June 20th to unblock email campaign. **Key points:** - Launch date moved from June 30th to July 15th - Landing page copy deadline: June 20th (blocks email campaign) - Campaign budget confirmed at $8,000 **Action item (if any):** Confirm receipt and deliver landing page copy by June 20th. ``` これが動くAIエージェントです。実際の入力、カスタムのシステムプロンプト、構造化された出力。全体でわずか30行のコードです。 ## ステップ4:あなたのユースケース向けにカスタマイズする システムプロンプトこそが、このエージェントをあなただけのものにする唯一の要素です。差し替えるだけで使える代替案を3つ紹介します。 **顧客レビュー分類器:** ```text Classify this customer review as POSITIVE, NEGATIVE, or MIXED. Then extract the main complaint or praise in one sentence. Format: SENTIMENT: