# 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 --- ## 人間の監視を組み込んだAIエージェント:承認ゲートをいつ構築するか(そしていつしないか) Source: https://alejandrorioja.com/ja/human-in-the-loop-ai-agents-when-to-build-an-approval-gate/ Published: 2026-07-23 Tags: AI Agents, Operations TL;DR: エラーが高コスト・不可逆・顧客向けで、人間が適時にそれを検出できる場合に、承認ゲートは意味を持つ。量が多すぎてレビューできない場合、エラーが安価に修正できる場合、または人が読まずに承認する場合には意味がない。私は4つの質問で判断し、本番の30以上のエージェントのほとんどに承認ゲートはない。 ## 目次 _2026年7月公開。_ **TL;DR:** エラーが高コスト、不可逆、または顧客向けで、人間が適時に検出できる場合に承認ゲートは意味を持つ。量が多すぎてレビューできない、エラーが安価に修正できる、または人が読まずに承認する場合には意味がない。4つの質問で判断し、本番の30以上のエージェントのほとんどは完全自動化で動いている。 **オペレーターのメモ:** 私はコンサルティングブランドとテキサス州プフラグヴィルのピックルボール施設Picklandという2つの事業でエージェントを運営している。最初は「安全」に感じて至る所に承認ゲートを設置した。数週間で、誰も読まない通知でいっぱいのSlackチャンネルと、技術的には監視されているが実質的に無監視のエージェントができあがった。これはゲートなしより悪い:監視の幻想、実質なし。この記事では今の私の意思決定方法を説明する。 ## 人間監視ゲートとは何か 最もシンプルに言えば、承認ゲートはエージェントのワークフローにおいて、エージェントが続行する前に人間が確認しなければならない一時停止だ。エージェントがメールの下書きを作成する——人間が送信前に承認する。エージェントが取引にフラグを立てる——人間が返金処理前にレビューする。 ゲートは同期式(誰かが承認するまでエージェントがブロックする)または非同期式(エージェントがアクションをキューに入れ、通知を送り、人間がダッシュボードやSlackメッセージから自分のペースで承認する)にできる。時間的に重要でないものには非同期がほぼ常に優れている。同期ゲートはキューに逆圧を生み、エージェントの信頼性保証を破る。 ゲートでないもの:リトライループ、信頼度閾値、またはより単純なモデルへのフォールバック。それらはエージェント内部のエラー処理メカニズムだ。承認ゲートは人間の判断がループに入ることに関係する——意図的に、特定の点で、理由を持って。 ## 私が問う4つの質問 ゲートを追加する前に、4つの質問を確認する。どれか一つに「はい」があれば検討のシグナル。全てに「はい」であれば、ゲートは構造的に必要だ。 **1. アクションは不可逆か(または元に戻すコストが高いか)?** 1万人にメールを送ることは取り消せない。支払いを送信することは簡単に呼び戻せない。バックアップなしにデータベースレコードを削除することは永久だ。不可逆性はゲートの最も強い論拠であり、エージェントは自分がしたことを元に戻せない。 比較:受信クエリにカテゴリタグを付けること。タグが間違っていれば、2クリックで修正できる。ゲート不要。 **2. エージェントが間違えた場合、誰が払うか?** 内部ラベルが間違い——数秒で修正。顧客向けメールが間違い——顧客が悪い体験で払い、私が信頼損失で払う。金融取引が間違い——実際のお金と潜在的なコンプライアンスリスクで払う。 内部システムにのみ影響するエージェントはゲートなしでより多くのエラーを許容できる。顧客やお金に触れるエージェントは無監視で動く権利を獲得する必要がある。 **3. 人間は重要になる前にエラーを実際に検出できるか?** これはほとんどの人が飛ばす質問で、他のどれよりも多くのゲートを排除する。エージェントが1時間に500件を処理し、アイテムごとにSlack通知を受け取る場合、誰も500件すべてを読まない。監視ではなく、アラート疲れを生み出している。 計算は単純:利用可能な時間ウィンドウ内でフラグ立てされたアイテムを現実的にレビューできる場合にのみ、ゲートは価値を追加する。 **4. 人間はエージェントが提示するものを確実に読んでいるか?** 承認キューが満杯になり人が読まずに承認するなら、ゲートはゲートなしより悪い——誰かが作業を確認したという誤った信頼を生む。 ## ゲートが明確に意味を持つとき これらは私が常にゲートを追加するパターン、例外なし: - **不可逆の外部コミュニケーション** — 実際の人へのメール、SMS、ソーシャルメディア投稿。エージェントが下書き;人間が送信。量に応じて。 - **閾値を超える金融アクション** — お金を動かすものは、コンテキストごとに設定する金額最低限を超える場合はゲートを設ける。 - **エージェントが見たことのない新パターン** — エージェントの分類器が何かを「不明」またはトレーニング分布外として分類した場合、それは強制エスカレーション。 - **コンプライアンス上慎重を要するアウトプット** — HIPAA、PCI、法的通知、または規制された金融コンテンツに触れるものは人がレビューする。 ## ゲートが密かに製品を殺すとき これらはゲートが安全に見えても密かに採用を壊すパターン: - **量が多く可逆な操作** — 2クリックで元に戻せて1日200回発生するなら、レビュー疲れが勝つ。 - **時間に敏感なワークフロー** — 30秒以内に受信顧客クエリに返答するエージェントに同期ゲートは不要。 - **人間がエージェントより少ないコンテキストを持つタスク** — エージェントが分類のために50ページのコンテキストを読み、レビュアーが1行サマリーを受け取るなら、レビューは形だけ。 - **内部エンリッチメントとラベリング** — CRMレコードのタグ付け、費用の分類、会議メモの要約。賭けが中断を正当化しない。 ## 私が実際に導入する3つのゲートパターン ゲートが正当化される場合、3つの実装から1つを選ぶ: **1. Slack/メール経由の非同期承認** エージェントが下書きを完成させ、提案アクションと承認/拒否ボタンを指定Slackチャンネルに投稿し、一時停止する。Cloudflare Queuesで保留アクションを保持し、再開前に承認webhookを待つ別のWorkerを使う。 適している:メール下書き、ソーシャルコンテンツ、重要なCRMアップデート。 **2. 信頼度ベースのエスカレーション** エージェントは高信頼度アウトプット(例:構造化スキーマで≥0.85の信頼度)に対して完全自動化で動き、低信頼度アイテムを人間キューにルーティングする。人間は曖昧なエッジケースのみ確認する。 適している:分類、ルーティング、トリアージ。 **3. バッチ承認によるダッシュボードレビュー** アイテムごとのゲートではなく、すべてのエージェントアウトプットがレビューダッシュボードに集まる。人間がバッチでレビュー——例えば毎朝——し、まとめて承認または修正する。 適している:コンテンツ生成、レポート下書き、スケジュールサマリー。 ## アラート疲れの落とし穴 追加するゲートすべては誰かの注意力への恒久的な課税だ。リスクは単一のゲートが無視されることではなく、3つのゲートが騒がしいSlackチャンネルを生み出し、人々が全通知を無視するよう訓練され、将来本当に重要なゲートも無視されることだ。 私が構築した規律:すべてのゲートには明示的なオーナーと明示的なSLAがある。SLA内で一貫してレビューする人がいなければ、ゲートは削除されて監査証跡に置き換えられる。すべての承認キューを月次監査する。 ## エージェント信頼性との接続 ゲートは信頼性スタックの1層であって、スタック全体ではない。本番エージェントの完全信頼性スタック: 1. **評価ハーネス** — デプロイ前に正しいアウトプットを確認。 2. **スキーマ検証付き構造化アウトプット** — エージェントのアウトプットは型付きスキーマに制約される。 3. **信頼度閾値** — 低信頼度アウトプットは人間レビューへ。 4. **監査ログ** — エージェントのすべてのアクションが入力、アウトプット、モデル呼び出しメタデータとともに記録される。 5. **人間承認ゲート** — 上記では不十分なアクションにのみ。 ゲートは最後の防衛線であって、最初ではない。 ## 私の経験則 初級スタッフに事前に相談なしにやってほしくないなら、エージェントにゲートが必要だ。初級スタッフに二度考えずにやってもらうなら、エージェントは無監視で動くべきだ。 ## FAQ ### 承認が必要だが量が多いエージェントをどう扱うか? アーキテクチャを変える:アイテムごとの承認を要求せず、パターンごとの承認を要求する。エージェントを動かしながら、統計的異常を人間のレビュー用に提示させる。 ### エラーが深刻な損害を引き起こし得るが完全な人間レビューを負担できない場合は? 通常、そのアクションに対してまだエージェントをデプロイしないサインだ。または、高度に確信する場合にのみエージェントが行動し、他のすべてをエスカレートする信頼度閾値を使う。[Claude](/recommends/claude)をモデル層として使う場合、Anthropic SDKのツール使用パターンにより、信頼度が不足した際にエージェントが呼び出せる「エスカレート」ツールを定義することが容易になる。 --- ## Claude Tool Use:AIエージェントに実際の能力を与える方法 Source: https://alejandrorioja.com/ja/claude-tool-use-production-agents/ Published: 2026-07-21 Tags: AI Agents, Claude TL;DR: Claude tool useを使えば、エージェントがテキスト生成だけでなく実際のアクションを実行できます。ツールをJSONスキーマとして定義し、Claudeがいつ呼び出すかを決定し、コードが実際のアクションを実行します。ループは3ステップ:メッセージ送信→tool_useブロック受信→実行して結果を返す。これをCloudflare Workersの15以上の本番エージェントに実装しました。障害点はほぼAIではなく、ツールから返ってくる曖昧な結果にあります。 ## 目次 _2026年7月更新。_ **TL;DR:** Claude tool useを使えば、エージェントがテキスト生成だけでなく実際のアクションを実行できます。ツールをJSONスキーマとして定義し、Claudeがいつ呼び出すかを決定し、コードが実際のアクションを実行します。ループは3ステップ:メッセージ送信→tool_useブロック受信→実行して結果を返す。これをCloudflare Workersの15以上の本番エージェントに実装しました。障害点はほぼAIではなく、ツールから返ってくる曖昧な結果にあります。 **[オペレーターの視点]** コンサルティングブランドとPickleland(テキサス州プフルガービルのピックルボール施設)で30以上の本番AIエージェントを運用しています。その約半数がtool use——コードで定義した関数をモデルが呼び出せるClaude APIの機能——を使用しています。本番環境での実装と反復を経て収束したパターンを紹介します。 ## Tool useがエージェントにできることを変える理由 ツールがなければ、エージェントはテキストを生成するだけです。要約、下書き、分類には便利ですが、ほとんどのビジネス自動化が実際に必要とするものではありません。ビジネス自動化には情報の検索、データベースへの書き込み、APIの呼び出し、メッセージの送信が必要です。 Tool useはClaudeにそのアクセス権を与える方法です。JSONスキーマとしてツールセットを定義します。Claudeはスキーマを読み込み、どのツールをどの引数で呼び出すかを決定し、構造化された`tool_use`コンテンツブロックを返します。コードが実際の関数を実行します。Claudeは結果を受け取り、次に何をすべきか決定します——別のツールを呼び出すか、最終的なテキスト応答を生成するかです。 重要点:**Claudeがツールをいつ、どのように呼び出すかを決定します。** 能力を定義するのはあなたです。モデルがいつ使用するかを推論します。 ## APIフローの仕組み Tool useループには3つのステップがあります。モデルが行うツール呼び出しの回数に応じて、このループを1回または複数回実行します。 **ステップ1:定義されたツールでメッセージを送信** ```typescript const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ { name: "check_court_availability", description: "Check if a court is available at a given date, time, and duration", input_schema: { type: "object", properties: { date: { type: "string", description: "Date in YYYY-MM-DD format", }, time: { type: "string", description: "Start time in HH:MM format (24h)", }, duration_minutes: { type: "number", description: "Duration of the booking in minutes", }, }, required: ["date", "time", "duration_minutes"], }, }, ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, ], }); ``` **ステップ2:Claudeがツールを呼び出したいか確認** ```typescript if (response.stop_reason === "tool_use") { const toolUseBlock = response.content.find( (block): block is Anthropic.ToolUseBlock => block.type === "tool_use" ); if (!toolUseBlock) throw new Error("Expected tool_use block"); // Run your actual function const toolResult = await checkCourtAvailability( toolUseBlock.input as CourtAvailabilityInput ); // Step 3: Return the result to Claude const finalResponse = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ /* same tools as before */ ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, { role: "assistant", content: response.content }, { role: "user", content: [ { type: "tool_result", tool_use_id: toolUseBlock.id, content: JSON.stringify(toolResult), }, ], }, ], }); // finalResponse.content now has the text answer } ``` これがパターン全体です。ツール呼び出し1回につき3回のAPIインタラクション:ツール定義→`tool_use`ブロック受信→結果を返す。 ## 実例:Pickleland空き状況チェッカー Pickleballはピックルボール施設です。Facebook Messenger、コメント、チャットボットで予約の問い合わせを受けます。質問はほぼ常に「土曜の午後3時は開いていますか?」や「8人グループでコートを予約できますか?」といった類のものです。 空き状況チェッカーエージェントは、定型文の回答を返す代わりに、tool useを使ってリアルタイムで実際の予約システムを照会します。 完全なエージェントを示します——簡略化していますが、本番環境に忠実です: ```typescript // workers/availability-checker.ts import Anthropic from "@anthropic-ai/sdk"; const anthropic = new Anthropic(); const AVAILABILITY_TOOLS: Anthropic.Tool[] = [ { name: "check_availability", description: "Check court availability for a date, time, and group size. Returns available courts and their prices.", input_schema: { type: "object", properties: { date: { type: "string", description: "YYYY-MM-DD" }, start_time: { type: "string", description: "HH:MM (24h)" }, duration_minutes: { type: "number" }, players: { type: "number", description: "Number of players" }, }, required: ["date", "start_time", "duration_minutes"], }, }, { name: "get_pricing", description: "Get current pricing for court rentals and open play sessions", input_schema: { type: "object", properties: { session_type: { type: "string", enum: ["court_rental", "open_play", "clinics"], }, }, required: ["session_type"], }, }, ]; export async function handleInquiry( userMessage: string, env: Env ): Promise { const messages: Anthropic.MessageParam[] = [ { role: "user", content: userMessage }, ]; // Agentic loop — keep going until stop_reason is "end_turn" while (true) { const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 512, system: "You are the booking assistant for Pickleland, a pickleball facility in Pflugerville, TX. " + "Use the tools to look up real availability and pricing. Never make up availability or prices. " + "If the customer wants to book, direct them to pickleland.com/book.", tools: AVAILABILITY_TOOLS, messages, }); // Push the assistant's response into message history messages.push({ role: "assistant", content: response.content }); if (response.stop_reason === "end_turn") { const textBlock = response.content.find( (b): b is Anthropic.TextBlock => b.type === "text" ); return ( textBlock?.text ?? "I wasn't able to answer that — please call us directly." ); } if (response.stop_reason === "tool_use") { // Process ALL tool calls in this response (Claude can request multiple at once) const toolResults: Anthropic.ToolResultBlockParam[] = []; for (const block of response.content) { if (block.type !== "tool_use") continue; let result: unknown; switch (block.name) { case "check_availability": result = await checkAvailability( block.input as AvailabilityInput, env ); break; case "get_pricing": result = await getPricing(block.input as PricingInput, env); break; default: result = { error: `Unknown tool: ${block.name}` }; } toolResults.push({ type: "tool_result", tool_use_id: block.id, content: JSON.stringify(result), }); } // Return all tool results in a single user message messages.push({ role: "user", content: toolResults }); } } } ``` 2点注目すべき点があります。 **エージェントループ。** `stop_reason === "end_turn"`になるまで続けます。Claudeは`check_availability`を呼び出し、料金も必要と判断して`get_pricing`を呼び出し、最終的な回答を生成するかもしれません——これは1つのユーザーメッセージに対する3回のAPI呼び出しです。ループは特別なロジックなしでこれを処理します。 **ターンごとの複数ツール呼び出し。** Claudeは1つの応答で複数の`tool_use`ブロックを返せます。すべてを処理し、単一の`user`メッセージですべての結果を返します。個別に処理して個別に返すと、会話の流れが壊れてトークンを無駄にします。 ## 実例:リード調査エージェント コンサルティングブランドでは、話す前にインバウンドリードを充実させる調査エージェントを使用しています。誰かが問い合わせフォームに記入すると、エージェントが会社を調査し、通話前に知る必要があることを抽出します。 このエージェントのツール定義には書き込みツールが含まれています——そこでパターンが面白くなります: ```typescript const RESEARCH_TOOLS: Anthropic.Tool[] = [ { name: "search_company", description: "Search for information about a company", input_schema: { type: "object", properties: { company_name: { type: "string" }, website: { type: "string", description: "Company website if known" }, }, required: ["company_name"], }, }, { name: "save_research", description: "Save the completed research summary to Airtable. Call this when all research is complete.", input_schema: { type: "object", properties: { company_summary: { type: "string" }, estimated_size: { type: "string", enum: ["1-10", "11-50", "51-200", "200+"], }, likely_use_case: { type: "string" }, priority: { type: "string", enum: ["high", "medium", "low"] }, notes: { type: "string" }, }, required: [ "company_summary", "estimated_size", "likely_use_case", "priority", ], }, }, ]; ``` `save_research`は**書き込みツール**と呼んでいます——情報取得が目的ではなく、Claudeの出力を構造化された形でデータベースに確定することが目的です。テキスト応答からJSONを解析する代わりにこのパターンを使用します。Claudeは調査が完了したことを知り、正しく型付けされたフィールドで`save_research`を呼び出します。パーサーを書く必要がありません。 これがtool useの最もクリーンな応用です:欲しい正確なスキーマで「最終アクション」ツールを定義すると、Claudeがツール呼び出しを通じて構造化された出力を提供します。テキストの解析なし、正規表現なし、自由テキスト出力のJSONSchema検証なし。 ## 1つのツール vs. 多数 tool useを始めるときの本能は、すべてを行う巨大なツールを作ることです。これに抵抗してください。小さく焦点を絞ったツールの方が優れています。理由は3つ: 1. **Claudeは小さなツールについてより適切に推論します。** `get_court_status`という名前のツールが空き状況を返す方が、`mode`パラメータを受け取り内部で分岐する`manage_facility`よりもモデルが処理しやすいです。 2. **小さなツールはテストが簡単です。** 各ツールはLLMとは独立してユニットテストできるTypeScript関数です。そうすべきです——ツールのバグはライブな会話の中でデバッグするのが困難です。 3. **Claudeは小さなツールを並列化できます。** 2つのツールが互いに依存していない場合、Claudeは同じ応答でそれらを呼び出し、並列に処理できます。これはツールが本当に独立している場合にのみ機能します。 例外:大量の共有内部状態へのアクセスが必要なツール。関数が同じデータソースから10個の変数を必要とする場合、それぞれがデータベースにアクセスする10個のツールよりも、より豊富なスキーマを持つ1つのツールの方が優れています。 私の経験則:異なる能力ごとに1つのツールから始めます。すべてのリクエストで一緒に呼び出しているのを見た場合にのみ、ツールをマージします。 ## コストの影響 tool useはトークンを追加します。各ツール定義はシステムプロンプトのコンテキストに入ります。各`tool_use`と`tool_result`ブロックは会話履歴のトークンを消費します。マルチターンのエージェントループでは、これが急速に積み重なります。 Pickleland空き状況チェッカーの場合、典型的な会話は合計3〜4回のAPI呼び出し(最初のメッセージ + 1〜2回のツール呼び出し + 最終回答)を実行し、それぞれ600〜900トークンを処理します。Haiku価格では、1リクエストあたり$0.001未満のコストです。[AIエージェントコスト計算の投稿](/ai-agent-cost-math-when-haiku-beats-sonnet/)で説明したように、Haikuは明確に定義されたツール呼び出しタスクを確実に処理し、同じトークン量でSonnetの10倍安価です。 リード調査エージェントはSonnetで動作しています。なぜなら、判断の決定——リードの優先順位付け、適合度の推定——は、Haikuがオープンな入力に対して確実に提供するよりも高い推論能力を必要とするからです。それほど頻繁に実行しないため(週数回、1日数千回ではなく)、計算はまだ機能します。モデルの選択はタスクの複雑さに従い、個人的な好みではありません。 ## 誰も話さない障害点 本番環境のtool useで見る最も一般的な障害点は、Claudeが間違ったツールを呼び出すことではありません。ツールがClaudeが明確に推論できないものを返すことです。 40フィールドを持つ生のデータベースオブジェクトを返すと、Claudeはどのフィールドが重要か混乱します。ツールが例外をスローする(ツール結果ではなくWorkerのクラッシュとして現れる)と、ループが静かに壊れます。ツールが「結果なし」を意味するときに`null`を返すと、Claudeは再試行するか諦めるか分かりません。 ツール結果の3つのルール: **コンパクトで明示的な結果を返す。** `{ available: true, courts: ["Court 3", "Court 5"], price_per_hour: 20 }`——完全なデータベース行ではなく。 **ツール関数内でエラーをキャッチし、構造化された結果として返す。** `{ error: "booking system timeout", retry: true }`——Workerをクラッシュさせるスローされた例外ではなく。 **「結果なし」を明示的にする。** `{ available: false, next_available: "2026-07-23T14:00:00Z" }`——コンテキストのない`null`や空の配列ではなく。 Claudeは曖昧な戻り値よりも明確なシグナルについてはるかによく推論します。本番環境でtool useのデバッグに費やした時間はすべて、モデルの推論ではなく不明確な結果についてでした。 ## オペレーターの結論 Tool useはClaudeをテキストジェネレーターからオペレーターに変える機能です。明確な入力スキーマを持つ焦点を絞ったツールを定義します。すべての`tool_use`ブロックをモデルへの単一の応答で処理します。`stop_reason === "end_turn"`になるまでエージェントループを実行します。ツール関数からクリーンでコンパクトな結果を返します——生のデータオブジェクトではなく、スローされた例外でもなく、曖昧なnullでもなく。 モデルが推論を担当します。コードが実際のアクションを担当します。この2つの仕事を明確に分離し続ければ、ツールを追加しても、アーキテクチャは維持可能なままです。 最初のtool useエージェントを構築している場合、上記の空き状況チェッカーパターンから始めてください——1つのツール、1つの目的、1つのエージェントループ。それをデプロイします。それから2番目のツールを追加します。 --- **関連記事:** [30以上の本番エージェントを運用するために使うエージェントスタック](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [Haiku vs Sonnet:エージェントタスクのコスト計算](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [イベントトリガーvs定期実行エージェント:どちらのパターンがどの仕事に向くか](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) **Tool useエージェントを構築していて行き詰まっていますか?** [お問い合わせ](/contact/)——オペレーターチームのために本番エージェントアーキテクチャを設計・構築しています。 ## よくある質問 ### Claude tool useはすべてのモデルで動作しますか? はい——tool useは現在のすべてのClaudeモデルでサポートされています。[Claude](/recommends/claude) Haikuは明確なスキーマを持つ明確に定義されたツールを確実に処理し、大容量タスクタイプの最も安価なオプションです。Sonnetはより曖昧またはオープンエンドなツール呼び出し決定をより適切に処理します。Haikuから始め、出力品質が不十分であれば上位モデルに移行します。 ### Claude tool useとOpenAIの関数呼び出しの違いは何ですか? 機械的に同一です。OpenAIが「function calling」を作り、AnthropicがそれをとしてI使っています。どちらの場合も:JSONスキーマを定義し、モデルが構造化された呼び出しを返し、コードが関数を実行します。APIの形式は異なりますが、概念は同じです。 ### Claudeは1つの応答で複数のツールを呼び出せますか? はい。Claudeは単一の`assistant`応答で複数の`tool_use`ブロックを返せます。すべてを処理し、単一の`user`メッセージですべての結果を返します。上記のPickleandの例のエージェントループパターンを参照してください——`response.content`上の`for`ループがこれを正しく処理します。 ### エージェントごとにいくつのツールを定義すべきですか? エージェントごとに8〜10個未満に抑えています。それ以上では、Claudeが最初の試みで間違ったツールを選択することがあり、修正ループでトークンを無駄にします。10以上の能力が必要な場合は、すべてを知る1つのエージェントを構築するのではなく、特殊なツールセットを持つ複数のエージェントにエージェントを分割します。 ### 構造化出力のためにtool useを使うべきですか? はい——`save_research`書き込みツールパターンは、Claudeにテキストブロックでをて返させてから解析するよりもクリーンです。欲しい正確なスキーマで「最終アクション」ツールを定義します。Claudeは完了したときに正しく型付けされたフィールドでそれを呼び出します。パーサーは不要です。 --- ## 2026年、検索エンジンは実際どうやってコンテンツの質を評価しているか Source: https://alejandrorioja.com/ja/how-search-engines-evaluate-content-quality/ Published: 2026-07-20 Tags: SEO, GEO ## 目次 _2026年7月公開。_ **TL;DR:** 検索エンジンもAIエンジンも、もはやページを単独で採点していません。評価しているのはサイト単位です——あるトピックをどれだけ深くカバーしているか、精査に耐える信頼シグナル、そして一本の傑作記事ではなく数か月にわたる一貫性です。私は384本の英語記事を13言語で展開し、ChatGPT、Perplexity、Google AI Overviewsに引用されているかを週次で追跡しています。パターンは一貫しています——孤立した記事は頭打ちになり、クラスターは複利で効き、引用率を動かす信頼シグナルは地味で構造的、そして安く作れるものだということです。 **運用者の視点:** コンテンツ品質について理論を語っているわけではありません——私はこのサイトのコンテンツエンジンを運営し、何かを変えたときに引用率がどう動くかを実際に見ています。この記事はすべて、alejandrorioja.comで実際に測定してきたことから組み立てています——実際のクラスターサイズ、実際に行った6週間の引用実験、実際のスキーママークアップのテスト。アルゴリズムが「おそらく」こう動くはずだという推測は一つも含まれていません。 ## 「品質」はもう、ページ単位の問題ではなくなった 多くの人がいまだに持っているメンタルモデルは「良い記事を書けば上位表示される」というものです。これは以前から完全には正しくありませんでしたが、狭いロングテールキーワード以外では、今や積極的に人を誤らせる考え方になっています。 自分のサイトで、これを直接確認する方法があります。私はいくつかの実在するクラスターにまたがって記事を公開しています——29本からなるAIエージェント・Claudeクラスター、Google、OpenAI、Anthropic、Uber、Salesforceなどを扱う「Xはどうやって儲けているのか」というビジネスモデル解説クラスター(20本まで拡大)、そしてタグ数で見てサイト最大のトピックであるSEO/GEOの大型クラスターです。一度しか触れていないトピックの単発記事は、客観的にはよく書けていたとしても、これらのクラスターの中に位置する記事とはまったく違う挙動をします。 クラスター内の記事はより多く引用され、順位もより安定し、アルゴリズムアップデート後の回復も速い傾向にあります。孤立した記事はスパイクするかしないかのどちらかで、しないときには頼れる周辺の権威がありません。これが、しばしば[AIトピカルオーソリティ戦略](https://www.linkbuildinghq.com/blog/how-to-build-topical-authority-for-ai/)として売り込まれているものの実際のメカニズムです——神秘的な信頼スコアではなく、同じテーマについて28本の他ページの隣に置かれているページは、Googleのクローラーにも、LLMのリトリーバル(検索・抽出)ステップにも、より多くの裏付けとなるコンテキストを与えるという単純な事実です。私はこの構造の[仕組みを丸ごと書き起こしました](/pillar-content/)——要点だけ言うと、クラスター内の全記事がピラー記事にリンクし、ピラーがそれぞれにリンクを返してこそクラスターは機能するということです。そうすることでトピックマップが明示され、クローラーが再構築する必要がなくなります。 新しい記事を公開する前に私が実際に使うテストはこうです——この記事はすでに持っているクラスターを拡張するのか、それとも新しい単発記事を始めるのか? 単発記事が禁止されているわけではありません——本当に一本のページだけで済むクエリも実際にあります——ただ、単発記事はページ単位のシグナルだけで勝負することになり、クラスター記事がタダで得られる複利効果は一切ないということを、公開前から分かった上でやっています。 ## 「本当に価値があり、水増しではない」は雰囲気ではなく検証可能な主張 この手のアドバイスの一般的なバージョンは「深みと文脈を加えろ、すでに広く知られている情報を繰り返すな」というものです。正しいのですが、検証する方法がなければ役に立ちません。 これが実際の規模で運用している私のテストです。私には384本の英語記事があります。そのすべてが、[まさにそのために作ったエージェント](/how-to-translate-one-blog-post-into-13-languages-with-one-agent/)によって他の12言語に翻訳されます。翻訳は安いです——341本分のバックログ全体でHaikuのAPI利用料は約1.70ドルでした。執筆はそうはいきません。もし同じアイデアを10通りの切り口で軽くリライトしてボリュームを水増しできるなら、そのエージェントは翻訳をスケールさせるのと同じくらい簡単に重複コンテンツもスケールさせてしまうでしょう。私はそれをしません。なぜなら、焼き直しの切り口は実際のテストを通らないからです——このページは、サイト内の他のどのページも同等以上にうまく答えていない問いに答えているか? どんなスタイルガイドラインよりも重要なフィルターはこれです。「水増し」はトーンの問題ではなく、重複の問題です——新しい切り口も、数字も、事例も加えずに、隣のページを言い換えているだけのページのことです。公開前に私がチェックするのは、新しい記事が新たな引用面を追加するのではなく、既存記事の引用を食い合ってしまわないかということです。サイト内の2本の記事が同じクエリを同じくらいうまく満たすなら、どれほどよく書けていても、片方は水増しです。 ## 実際に構築し、測定してきた信頼シグナル 「信頼性」は、あらゆる一般的なSEO記事の中でもっとも曖昧な言葉です。たいてい「情報源を引用する、専門性を示す、正確さを保つ」といったリストが続きますが、それが何かを動かしたのかを検証する方法はありません。 私が実際に運用している具体的なバージョンはスキーママークアップです。これはAIエンジンが推論ではなく機械的にパースする、唯一と言っていい信頼シグナルだからです。[実装の全体像](/schema-markup-for-geo/)は別記事でまとめ、[実際に効くタイプ](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/)についてはさらに掘り下げました。要点だけ言うと——実名の著者と正直な`dateModified`を伴う`Article`/`BlogPosting`が著者性のアンカーになり、`FAQPage`と`HowTo`は最も効果が高いタイプです。文章から推論させる代わりに、あらかじめ答えられた質問や構造化された手順をモデルに手渡すからです。`Person`と`Organization`スキーマは、モデルが私を同姓同名の別人と混同しないために存在します。 これは私にとって抽象論ではなく、実際の結果の背後にある介入です。すでにGoogle AI Overviewsをトリガーしていた41本のピラー記事に、4パーツからなる構造オーバーレイ(TL;DRブロック、番号付きステップ、FAQセクション、一次情報源の引用)を適用したところ、6週間で引用頻度が41本中4本から41本中19本に上昇しました——[6週間のテストの全容はこちら](/google-ai-overview-citation-case-study/)にまとめています。これは「信頼シグナルを足して祈る」という話ではありません。自分のページで測定したビフォー/アフターであり、記事自体がはっきり述べている留保も伴います——これはすでにオーガニックでトップ5にランクインし、権威の下地があったページでのみ機能したということです。構造は既存のシグナルを増幅するのであって、何もないところから権威を作り出すわけではありません。 ## 一貫性は複利で効く——ただし「一貫性」は絶え間ない更新を意味しない この点についての一般的な主張は、たいてい「鮮度は重要だが、すべての記事を更新する必要はない」というもので、実際の頻度は示されません。ここでは私自身のものを示します。 公開後、ほとんどの記事には手を加えません。ただし、一定のピラー記事群はローリングで維持しており、基礎となる事実が動いたとき——新しいモデルがリリースされた、ツールの価格が変わった、統計が古くなった、といったとき——には6〜12か月ごとに更新します。`dateModified`はコンテンツが実際に変わったときにしか変更しません。日付だけ偽装するテストもしてみましたが、うまくいきません——実質的な編集を伴わずに日付だけ更新しても、エンジンには見抜かれます。これはまさに、AI Overviewのケーススタディでも判明したことです。 私が実際に週次で見ている一貫性のシグナルは公開頻度ではなく、引用カバレッジです。ビジネス上重要なクエリのトラッキングリストを、ChatGPT、Perplexity、Googleに毎週通し、引用されているかを記録しています——[方法論はこちら](/how-to-measure-ai-search-traffic/)。引用カバレッジは先行指標です——リファラルトラフィックやブランド検索の上昇より先に動くため、クラスターが実際に時間とともに権威を積み上げているのか、それとも単に存在しているだけなのかを教えてくれる数字です。一度公開して静かになるサイトは、この週次チェックで二度目の注目を得ることはありません。クラスターを拡張し続けるサイトはそうではありません。 ## 「サイト単位」の評価が実際に報いるもの——レイヤーごとに 私が追跡している3つのエンジンは、同じシグナルを同じ重みでは評価していません。どこに労力を投資するかを決めるとき、私が頭の中に持っている実務上の表がこれです。 | 品質レイヤー | 実務上どう現れるか | どこで測定したか | | --- | --- | --- | | トピックの深さ | 一つの主題について20〜30本以上の相互リンクされた記事、ピラーが各クラスター記事にリンクし、また戻ってくる | AIエージェントクラスター(29本)、「Xはどうやって儲けているのか」クラスター(20本) | | 構造的な抽出しやすさ | TL;DRブロック、番号付きステップ、FAQ、実際のユーザーの言い回しに合わせた表現 | 6週間でAI Overview引用が41本中4本→19本 | | 著者性・信頼性 | 実名の著者 + 正確な`dateModified` + Person/Organizationスキーマ | GEOのためのスキーママークアップ、スキーマタイプの内訳 | | 時間軸での一貫性 | 絶え間ないリライトではなく、エンジン横断の週次引用トラッキング | AI検索の測定方法論 | 一般的なアドバイスで最もよく見かける失敗パターンは、これらを一つの区別されない「品質」スコアとして扱うことです。実際にはそうではありません。あるページは構造的な抽出しやすさを完璧にこなしていても、トピックの深さで勝る競合に負けることがあります。あるページは深いクラスターの中にありながら、より新しく、より良いスキーマを持つ競合に特定の引用で負けることがあります。あるページにとって実際のボトルネックがどのレイヤーなのかを見極めることが、仕事の大部分を占めます。 ## この考え方が崩れるところ——正直な留保事項 このパターンを過大評価するより、限界を正直に示しておきたいと思います。 - **ドメインオーソリティは依然としてゲートです。** AI Overviewの介入は、すでにオーガニックでトップ5にランクインしていたページでのみ機能しました。構造は既存のシグナルを増幅しただけで、何もないページから権威を生み出したわけではありません。 - **エンジンは何を評価するかで食い違います。** 同じ50個のヘッドタームをChatGPTとGoogleに通したところ、引用されるソースの重なりは約40%しかありませんでした——[全内訳はこちら](/chatgpt-search-vs-google-50-term-test/)。「検索エンジン」を単一のターゲットとして最適化しようとすること自体がすでに間違ったフレームです。実際には、基本部分では一致し、それ以外では食い違う複数のエンジンを相手に最適化していることになります。 - **カテゴリーによっては本当にクラスターを必要としないものもあります。** 私の最も成果の高いページの中にも、純粋な単発記事がいくつかあります。深さは一つのレバーであって、普遍的な要件ではありません——クエリ空間がそれをサポートしていないのにクラスターを無理に作ると、このフレームワーク全体が避けようとしている、まさに薄っぺらく水増しされたコンテンツができあがります。 ## よくある質問 ### 一本の優れた記事が、平凡なクラスターより上位表示されることはあるか? あります。競争の少ない十分に狭いクエリであれば。しかし本当に競争のあるヘッドタームでは、長期的に順位を維持するページはほぼ例外なくクラスターに支えられています。孤立した記事がスパイクして消えていくのを、クラスター記事にはない形で何度も見てきました。 ### トピックが本物のクラスターとしてカウントされるには何本の記事が必要か? 厳密な数字はありませんが、自分のデータでは、同じ主題のサブトピックについて本当に異なる内容の記事が8〜10本程度になったあたりから、効果がはっきり見え始めます。ピラーが意味のある形でリンクを張れるだけの本数があり、各クラスター記事にも、より深い情報を求める読者を具体的に送り込める先があるということです。 ### スキーママークアップは本当に必要か、それとも良い文章さえあれば十分か? 良い文章は必要ですが、特にAIエンジンからの引用に関しては十分ではありません。エンジンは、文章だけよりも`FAQPage`や`HowTo`スキーマからの方が構造化された事実をより確実に抽出します。スキーマが推論のステップを取り除くからです。それまでスキーマのなかった記事に追加したことで、一桁台後半から10%台半ばのポイントの引用率上昇を実測しています。 ### 新しい記事を公開する代わりに、古いコンテンツはどのくらいの頻度で更新すべきか? 実際の事実が変わったときに、ピラー記事は6〜12か月ごとに更新しています。実質的な編集を伴わずに`dateModified`を更新することは決してありません。私のコンテンツ予算の大半は、リライトではなく新しいクラスター拡張記事に充てています——鮮度は重要ですが、トピックの深さや構造と比べると支配的なレバーではありません。 ### 最初に直すべき、最もレバレッジの高い一点は何か? あるページがすでにオーガニックでそれなりに上位表示されているのに、AIエンジンに引用されていないなら、ヘッドクエリに直接答える明快なTL;DRブロックを追加してください。私自身の6週間のテストでは、これが群を抜いて最大の単一レバーでした——FAQスキーマよりも、一次情報源の引用よりも、番号付きステップよりも大きな効果でした。 ## 結論 コンテンツ品質の評価はページ単位からサイト単位へと移り、実際に針を動かすサイトレベルのシグナルは、神秘的なものではなく測定可能なものです——数えられるクラスターの深さ、A/Bテストできる構造オーバーレイ、検証できるスキーマ、そして週次で追跡できる引用カバレッジの数字。そのどれもが、アルゴリズムが「何を望んでいるか」を推測することを必要としません。必要なのは、本物のトピック構造の中で公開すること、エンジンに推論させる代わりに明快で抽出しやすい答えを渡すこと、そしてそれがうまくいっているかを知るのに十分な頻度で結果をチェックすることです。私はこの4つの規律すべてを、このサイトで毎週実行しており、上に挙げた数字は、一般的なガイドが「こうなるはずだ」と主張する数字ではなく、実際にそれらが生み出した数字です。 --- ## 2026年のビジネス向けClaudeとChatGPTの比較:オペレーターの正直な見解 Source: https://alejandrorioja.com/ja/claude-vs-chatgpt-for-business-2026/ Published: 2026-07-18 Tags: AI Agents, Productivity TL;DR: Claudeはエージェント構築、長文脈での作業、コーディング、そしてスケールで本番環境で動くすべての点で勝ります。ChatGPTは消費者向けインテグレーション、音声モード、そしてワークフローがチットインターフェースに依存している場合のより広いプラグインエコシステムで勝ります。自動化ワークフローやAIエージェントを構築しているなら、Claudeがより良い基盤です。より多くのサードパーティ接続を持つ有能なチットアシスタントが必要なら、ChatGPTが有利です。ほとんどのビジネスオーナーにとって、本当の質問は:AIと会話しているのか、AIで構築しているのか?その答えがツールを決定します。 ## 目次 _2026年7月公開。_ **TL;DR:** Claudeはエージェント構築、長文脈での作業、コーディング、そしてスケールで本番環境で動くすべての点で勝ります。ChatGPTは消費者向けインテグレーション、音声モード、そしてワークフローがチットインターフェースに依存している場合のより広いプラグインエコシステムで勝ります。自動化ワークフローやAIエージェントを構築しているなら、Claudeがより良い基盤です。より多くのサードパーティ接続を持つ有能なチットアシスタントが必要なら、ChatGPTが有利です。ほとんどのビジネスオーナーにとって、本当の質問は:AIと会話しているのか、AIで構築しているのか?その答えがツールを決定します。 **[オペレーターの視点]** 私は2つのビジネスを経営しています — コンサルティングブランドと、テキサス州プフルーガービルにあるピックルボール施設のPickleland — ソーシャルメディア返信、イベントプロモーション、予約フォローアップ、ニュースレター草稿などを処理する30以上のAIエージェントを本番環境で運用しています。エージェントスタック全体が[Claude](/recommends/claude)上に構築されています。ChatGPTもそれぞれの弱点を把握できるほど使ってきました。これはベンチマークレビューではありません。実践者の視点です。 ## 本当に重要な質問 ほとんどの比較は「どのモデルが賢いか?」と問います。これはビジネス利用における間違った質問です。 正しい質問は:**何を構築していて、それをスケールで信頼性高く何をする必要があるか?** AIがコピー作成を手伝ってほしいマーケティングマネージャーは、自動化されたリード資格認定パイプラインを構築するファウンダーとは異なる要件を持っています。会議の準備にAIを使うソロプレナーは、週500件の顧客リクエストを処理するエージェントを構築するオペレーターとは異なるニーズを持っています。一方が勝つツールは、もう一方には間違いであることが多い。 このフレームが以下のすべてを決定します。 ## Claudeが勝る点 ### 1. 長文脈での作業 Claudeのネイティブコンテキストウィンドウ — 20万トークン — は他のモデルを壊す作業を処理します。私は定期的に完全な顧客会話履歴、契約草稿全体、または複数文書の調査まとめをClaudeに渡し、合成またはクロスリファレンスを求めます。スレッドを保ちます。競合モデルは今や技術的に長いコンテキストをサポートしていますが、複雑なタスクでの実際の劣化はまだClaudeより悪い。 長い文書の読み込み、密なデータエクスポートの分析、または長いワークフローでの一貫性の維持を含むビジネスタスクでは、Claudeには本物の優位性があります。 ### 2. 本番環境でのエージェント動作 Claudeをエージェントとして実行するとき — ツールを呼び出し、ループで決定を下し、データベースに書き込み、エラーを処理する — 私の経験ではChatGPTよりも一貫して動作します。システムプロンプトの指示をより確実に従い、より解析しやすい構造化出力を生成し、コンテキストが長くなってもタスクから外れる可能性が低い。 これはエージェントにとって非常に重要です。システムプロンプトを95%の時間対99%の時間で従うモデルは似て聞こえます。1日500回のコールで、それは検出して修正が必要な1日25件のドリフトケースです。 [本番環境で失敗しないAIエージェントシステムプロンプトの書き方](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/)についての記事で詳しく説明していますが、短いバージョンは:システムプロンプトレベルでのClaudeの指示遵守は私がテストした中で最高です。 ### 3. コーディングと技術作業 私はほぼすべてをCloudflare Workers上のTypeScriptで構築します。Claude Codeは私の日常的な開発ツールです — そして「十分良い」ではなく、本当に役立ちます。アーキテクチャの質問、デバッグ、リファクタリング、スクラッチからのエージェントロジック記述において、ClaudeはChatGPTの同等品で使ったものを一貫して上回ります。 これはClaude CodeとChatGPT Chatの比較だけではありません。API経由の生Claude Opus 4.8でも、同じタスクでGPT-4o同等品よりも幻覚インポートが少ないクリーンなコードを書きます。 ### 4. APIでの開発者体験 APIで構築している場合 — 単にチャットするのではなく — 2026年ではClaudeの開発者体験が優れています。Anthropic SDKはクリーンで、トークンカウントエンドポイントはコスト見積もりに本当に役立ち、プロンプトキャッシングはよく実装されており繰り返しコンテキストで実際のコストを節約し、エラー処理は予測可能です。 プログラムでエージェントを構築するすべての人にとって、API品質のギャップは重要です。大きくはありませんが、一貫しています。 ### 5. 複雑なプロンプトでの指示忠実性 Claudeは複数の条件を持つ微妙なシステムプロンプトをChatGPTよりもうまく処理します。エージェントがルールセットに従う必要があるとき — 「コメントが質問なら、Xをする;苦情なら、Yをする;競合他社に言及するなら、人間レビューのためにフラグを立てる」 — Claudeはそれらのブランチをより一貫して解析し適用します。 シンプルなプロンプトでは差は最小限です。システムプロンプトに埋め込まれた複雑な条件ロジックでは、Claudeがより信頼できます。 ## ChatGPTが勝る点 ### 1. 消費者向けインテグレーションとプラグイン ChatGPTのプラグインエコシステムとネイティブインターフェース経由で利用可能なツールの範囲は広い。ワークフローがすでにChatGPTのネイティブインテグレーションを持つツール — 特定のCRM、生産性アプリ、研究ツール — に住んでいて、主にチャットインターフェースを通じて作業するなら、ChatGPTのアウトオブボックス接続がフリクションを節約します。 カスタムインテグレーションを構築せずにチャットUIからすべてを行いたいパワーユーザーには、これが重要です。 ### 2. 音声モード ChatGPTのAdvanced Voice Modeは本当に優れています。モバイル使用、口頭でのアイデア整理、または運転中の通話準備のために、これは私が使った中で最高の音声AIインターフェースです。Claudeには音声入力がありますが、2026年中頃の時点でGPT-4oの完全な会話音声モードに匹敵するものはありません。 音声がユースケースの主要インターフェースなら、ChatGPTが明確に勝ります。 ### 3. 画像生成(DALL-E経由) ChatGPT Plusは同じサブスクリプションにDALL-E経由の画像生成を含みます。ClaudeはネイティブでMAGES画像を生成しません。MidjourneyやOther other serviceを追加せずにテキストと画像作業の単一ツールが必要なら、ChatGPTに優位性があります。 ### 4. 親しみやすさと普及 より多くの人がChatGPTを使ったことがあります。AIの経験がないチームにAIツールを紹介するなら、ChatGPTで始める方が摩擦が少ない — ほとんどの人が少なくとも一度は開いたことがあります。これは能力上の優位性ではありませんが、オンボーディング速度は実際の運用要因です。 ## コスト比較 ここが細かくなるところで、ほとんどの比較が誤解を招く場所です。 両プラットフォームには階層価格があります。APIレベルでは: - **Claude Haiku 4.5**と**GPT-4o mini**は高ボリュームの単純なタスクのための安価なワークホースです。価格帯は比較可能で、選択は主にタスク要件によって決まります。 - **Claude Sonnet/Opus**と**GPT-4o**は中から高レベルです。Claudeには[プロンプトキャッシング](/prompt-caching-cut-your-claude-costs-without-switching-models/)があり、繰り返しコンテキストのワークフローでコストを大幅に削減します — エージェントが呼び出し間で同じシステムプロンプトとコンテキストウィンドウを再利用する場合、Claudeのキャッシュ価格は非キャッシュレートより50〜80%安くなる可能性があります。ChatGPTには直接の同等品がありません。 - 最上位レベルでは、Claude Fable 5と最新のGPT-4バリアントは同じ基本コスト範囲にありますが、トークナイザーの違いが重要です — Fable 5は以前のモデルとは異なる方法でトークンをカウントするトークナイザーを持っているので、参照トークン数は直接変換されません。 コストの結論:**高コールボリュームの本番エージェントでは、Claudeのプロンプトキャッシングがコンテキストを再利用するワークロードで実質的に安くなります。** 新鮮なコンテキストでの純粋なペイパーコールでは、パフォーマンスが選択を導くべきで、定価ではありません。 これを評価するために使うフレームワークは[AIエージェントコスト計算の記事](/ai-agent-cost-math-when-haiku-beats-sonnet/)にあります。 ## 決定マトリクス | ユースケース | 勝者 | |---|---| | 本番でのAIエージェント構築 | Claude | | 複雑なコーディングとアーキテクチャ | Claude | | 長文脈ドキュメント分析 | Claude | | プラグインインテグレーション付きチャットアシスタント | ChatGPT | | 音声を主要インターフェースとするワークフロー | ChatGPT | | 1つのインターフェースで画像+テキスト | ChatGPT | | スケールでのAPI駆動自動化 | Claude | | AI経験なしのチームオンボーディング | ChatGPT | | 本番での顧客向けエージェント | Claude | | 高ボリュームパイプラインでのコスト効率 | Claude(キャッシングあり) | ## 私の実際の答え 私は本番のすべてに[Claude](/recommends/claude)を使います。すべてのベンチマークで勝つからではなく — そうではない — 以下の理由からです: 1. エージェントがシステムプロンプトの指示に十分確実に従うため、幻覚またはオフタスク出力のクリーニングにほぼ時間を費やしません。 2. Cloudflare Workers + Claude APIスタックは私の合計ワークロードで月$100未満で、プロンプトキャッシングが最も重いワークフローのコストを半分以上削減しました。 3. Claude Codeが主要コーディングインターフェースになり、開発と本番の両方に同じモデルを使うことでメンタルモデルがシンプルになります。 4. 長文脈タスク — PDFの読み込み、文書横断の合成、マルチステップワークフローでの一貫性の維持 — ClaudeはFull 200Kウィンドウを他で経験したよりもうまく処理します。 カスタムインフラを構築せずにAI支援ツールが必要なチームを率いるなら、おそらくChatGPT Plusに置くでしょう — アウトオブボックスのプラグイン幅と音声モードは消費者レベルで本当に役立ちます。しかし単に使うのではなく何かを構築するには、Claudeが正しい基盤です。 ## よくある質問 ### ClaudeはChatGPTより賢いですか? どちらも普遍的に賢いわけではありません。Claudeは長文脈推論、指示遵守、コーディングに優れています。ChatGPT(GPT-4o)は画像と音声を含むマルチモーダルタスクに優れています。特定のベンチマークはモデルリリースごとに彼らの間で入れ替わります。より有用な質問は、あなたの特定のタスクにどのモデルが優れているかです。 ### ClaudeとChatGPTの両方を使えますか? はい、いくつかのワークフローでそうしたい場合があります。Claude APIとOpenAI APIはどちらも統合が簡単です。いくつかのチームはエージェントバックエンドにClaudeを使い、インテグレーション付きのユーザー向けチャットインターフェースにChatGPTを使います。ただし、2つのAIプロバイダーを運用すると運用上の複雑さが増します — 資格情報管理、コスト追跡、管理すべき動作の違い。1つから始めてください。 ### コンテンツライティングにはどちらが優れていますか? 私の経験ではClaude。より一般的でない出力を生成し、例が与えられると特定のスタイルをよりうまく維持し、長文コンテンツをより一貫して処理します。どちらでも機能する短いソーシャルコンテンツやメールでは、差は小さい。 ### Claudeには無料枠がありますか? はい — Claude.aiにはメッセージ制限付きの無料枠があります。[Claude ProとMaxサブスクリプション](/recommends/claude)は制限を削除し、優先アクセス、ファイルアップロード、完全なコンテキストウィンドウを追加します。ChatGPTも同様に使用制限付きGPT-4oアクセスの無料枠があります。 ### ChatGPTからClaudeに乗り換えるべきですか? 主にAIをチャットインターフェースとして使用していてChatGPTに満足しているなら、Claudeがより良く処理する特定のニーズがない限り、乗り換えコストは割に合わないかもしれません。自動化、エージェントを構築したり、コーディング作業をしているなら、Claudeを試すことを強くお勧めします — エージェントの動作と開発者体験は本番ワークロードで大きな違いをもたらします。 --- ## プロダクタイズドサービスの構築方法:専門知識をスケーラブルな収益に変える私のフレームワーク Source: https://alejandrorioja.com/ja/productized-service-how-to-package-your-expertise/ Published: 2026-07-16 Tags: Entrepreneurship, Marketing TL;DR: プロダクタイズドサービスとは、毎回同じ方法でデリバリーする固定スコープ・固定価格のオファーです。4つのステップ:クライアントがすでに繰り返し依頼している仕事を見つける、スコープの境界を明確に定義する、成果の価値(時間ではなく)に基づいて価格を設定する、次のクライアントに売る前にデリバリーシステムを構築する。ほとんどのコンサルタントはステップ4をスキップし、時間をお金と交換し続けます。それが本当にスケールを生み出す唯一のステップです。 ## 目次 _2026年7月公開。_ **TL;DR:** プロダクタイズドサービスとは、毎回同じ方法でデリバリーする固定スコープ・固定価格のオファーです。4つのステップ:クライアントがすでに繰り返し依頼している仕事を見つける、スコープの境界を明確に定義する、成果の価値(時間ではなく)に基づいて価格を設定する、次のクライアントに売る前にデリバリーシステムを構築する。ほとんどのコンサルタントはステップ4をスキップし、時間をお金と交換し続けます。それが本当にスケールを生み出す唯一のステップです。 **[オペレーターノート]** 私は何年もカスタムコンサルティング案件を行ってきました——それぞれ異なるスコープ、異なる価格、異なるデリバリー方法で。その結果、すべてのプロジェクトで直接的な注意が必要なビジネスになっていました。プロダクタイゼーションがそれを変えました:最も需要の高い仕事を、明確な成果物、固定価格、繰り返し可能なデリバリープレイブックを持つ定義されたオファーに変えることで。ここに正確なフレームワークと、構築過程での失敗を紹介します。 ## プロダクタイズドサービスとは実際に何か プロダクタイズドサービスはリテイナーではありません。サブスクリプションでもありません。固定スコープ、固定価格、そして毎回同じ方法で機能するほど十分に文書化されたデリバリープロセスを持つ、定義された繰り返し可能なオファーです。 カスタムコンサルティングとの対比:「スコープに応じて$X〜YのAI自動化戦略を提供します」ではなく、「AIオートメーションロードマップ:5つのワークフローの書面による監査、優先ビルド推奨事項、30分のデリバリーコールで$2,500」を販売します。スコープ固定。価格固定。タイムライン固定。唯一の変数はクライアントがYesと言うかどうかです。 リテイナーとの違いはプロジェクトベースであること。明確な開始。明確な終了。オープンエンドの月次請求なし、スコープの拡大なし、事後の「これも見てもらえますか?」という会話なし。 スケーラブルにするもの:システムであり、オファーではありません。固定価格のオファーは、再価格設定されたカスタム作業に過ぎません。プロダクタイズドサービスには、その背後にデリバリープレイブックがあります。 ## ステップ1:クライアントがすでに依頼している仕事を見つける 構築が最も簡単なプロダクタイズドサービスは、すでに繰り返しデリバリーしているが毎回カスタム作業として扱っているものです。 直近の10〜15のクライアントやプロジェクトを振り返り、パターンを探してください: - 最も頻繁に出てくる問題は何ですか? - 最も頻繁に生産する成果物は何ですか? - どのタイプの案件が最もスムーズに進み、最良のクライアントフィードバックを得ますか? 私の場合、パターンは明確でした:クライアントが常に同じことを求めていました——プロセスのマッピング、何を自動化するかの選択、構築に適したツールの選定。繰り返し行っていましたが、毎回異なるスコープで。 そのパターンが出発点です。市場が必要としていると思う新しいサービスではありません。すでに行っていることです。 一つのフィルター:すべてのクライアントにとって成果物が大部分同じである作業のみをプロダクタイズします。各クライアントがまったく異なる成果物を受け取る場合、その作業はまだプロダクタイズできません——それはまだ真にカスタムです。それで構いません。定義作業が最初に来るということです。 ## ステップ2:スコープの境界を定義し、守る ここでほとんどのコンサルタントが失敗します。オファーを曖昧に定義し、スコープを解釈に開いたままにして、以前と同じスコープ拡大の会話に陥ります。 プロダクタイズドサービスには硬いスコープの境界が必要です。最初の販売コールの前に、書面で含まれるものと含まれないものを定義します。 AI自動化戦略スプリントのスコープ定義例: **含まれるもの:** - 60分の構造化されたインテークコール - 最大5つのワークフローの書面による監査 - ツール推奨事項付きの優先自動化ロードマップ - トップ3候補のビルド対購入評価 - 30分のデリバリーウォークスルーコール **含まれないもの:** - 実装(エージェントや統合の構築) - デリバリー後の修正 - 5つ以上のワークフロー - 合意した自動化スコープ外の作業 「含まれないもの」リストは「含まれるもの」リストと同様に重要です。クライアントが境界外の何かを求めた場合、2つの選択肢があります:このオファーの範囲外であると伝えるか、独自の価格で範囲を指定したアドオンを作成するか。しないことはそれを吸収することです。 最初はこれが不快に感じます。クライアントを満足させるためにYesと言うことに慣れています。プロダクタイゼーションは「それは別のプロジェクトです」と言うことを要求します——そして一貫してそれを意味することを。 ## ステップ3:成果の価値に基づいて価格を設定する 時間給とプロダクタイズドサービスは混在しません。自分の時間に基づいて計算し始めた瞬間、再びカスタム作業にしてしまっています。 プロダクタイズされたオファーの価格設定の3つの変数: 1. **クライアントが問題を解決しないコスト。** 月間$4,000の業務効率を解放するAI自動化ロードマップは、購入者にとって数千ドルの価値があります。あなたの8時間の作業は間違った価格のアンカーです。 2. **購入者が同等の成果に費やすもの。** 競合他社が請求するものではなく——クライアントがコンサルタント、フラクショナルエグゼクティブ、または問題を部分的に解決するソフトウェアから類似した結果に実際に費やすもの。これがあなたの上限を設定します。 3. **あなたの最低限の下限。** デリバリー時間、クライアント管理、オーバーヘッドを考慮して、このオファーで注意を払う価値があるために稼ぐ必要があるのはいくらですか?これがあなたの下限を設定します。 そのレンジで価格を設定します。初期のプロダクタイズされたオファーでは、中間から始めます。推薦文を集め、デリバリー速度を磨くにつれて、上限に向かって動きます。 値引きしないでください。誰かがオファーを払えない場合、彼らはそれに適したクライアントではありません。別のセグメントのために低価格のオファーを構築できます——しかし臨時の値引きで主要なオファーを薄めないでください、そうしないとカスタム価格設定に戻ります。 ## ステップ4:次の販売前にデリバリーシステムを構築する このステップは、プロダクタイズドサービスがあるのか、それとも固定価格の案件があるだけなのかを決定します。 最初のデリバリーの後——次のクライアントに販売する前に——これを行います: 1. **順番に各ステップを文書化します。** 曖昧なアウトラインではなく。そのドメインに精通した人が80%のプロセスをそこから実行できるほど詳細なチェックリスト。これらを[Notion](/recommends/notion)に保存しています——ワークフローステップごとに1ページ、テンプレート、出力例、難しい判断のための意思決定ツリー付き。 2. **予想より長くかかったことを特定します。** 最初のデリバリーは常に必要以上に遅い。ボトルネックを見つけてシステム化します:インテークフォーム、成果物テンプレート、事前構築されたフレームワーク。 3. **構造化されたインテークプロセスを構築します。** コールの前に標準化されたフォームでクライアントの情報を得ることが、デリバリーを予測可能にするものです。コールは明確化の質問のためであり、情報収集のためではありません。 4. **成果物テンプレートを作成します。** 各クライアントは同じ出力構造を受け取ります。コンテンツは変わります;構造は変わりません。これによってデリバリーが速くなり、出力が毎回一貫してプロフェッショナルに見えます。 このステップをスキップして次のクライアントに販売するだけなら、まだカスタム作業を行っています——それに固定価格を付けただけです。システムこそが本当にスケーラブルにするものです。 ## プロダクタイゼーションが実際に解放するもの 主な利点は高い収益ではありません。より良い収益です:予測可能な需要、より速いデリバリー、交渉の会話が少なくなり、オファー外のものを求めるクライアントにNoと言える能力。 第2の利点:デリバリー文書が知的財産になります。プロダクタイズされたコンサルティングオファーのために構築するプレイブックは、コースやトレーニングプログラムのコンテンツの大部分です。私はAI自動化コンサルティングでこれを行いました——デリバリープレイブックは直接私のAI Agents for Beginnersコースのカリキュラムの骨格になりました。 第3の利点:レバレッジ。文書化されたシステムがあれば、インテークとデリバリーコールに集中しながら、デリバリーの一部——監査、調査、文書作成——を実行するように人を訓練できます。それが一対一の時間対お金のトレッドミルから降り始めることです。 ## プロダクタイズされたオファーを管理するために使用するツール **[Airtable](/recommends/airtable)** ——クライアント案件ごとに1行、ステータス、成果物リンク、支払いをトラッキング。複雑さなしに1クライアントから50クライアントまでスケールします。 **[Notion](/recommends/notion)** ——デリバリープレイブックとクライアント向けワークスペース。各クライアントは、繰り返しのデリバリーで磨かれたテンプレートから構築された共有Notionワークスペースを受け取ります。 **[ConvertKit](/recommends/convertkit)** ——ウェイティングリスト管理とフォローアップシーケンス。オファーが満杯になったとき(固定スコープの作業では容量はすぐにいっぱいになります)、ウェイティングリストシーケンスは次の開きまで温かいリードのエンゲージメントを維持します。 ## 最もよく見る失敗 **十分にデリバリーする前にプロダクタイズする。** この作業を3〜5回行っていなければ、まだ本当のスコープを知りません。最初はカスタム作業としてデリバリーします。境界がどこにあるかを学びます。それからプロダクトを定義します。 **スコープを曖昧にする。** 未定義のスコープを持つプロダクタイズドサービスは固定価格のカスタムプロジェクトです——これは両方の世界の最悪です。何が含まれているかを定義し、何が含まれていないかを定義し、書面に記し、販売ページに載せます。 **スコープ外の要求にYesと言う。** クライアントがより多くを求めたとき、独自のスコープと価格を持つアドオンを作成します。今回だけ吸収しないでください。 **デリバリーシステムをスキップする。** 最初のデリバリー後に終わっていません。2番目を販売する前にプレイブックを構築します。システムこそがプロダクトを作るものです。 ## FAQ ### いくつのプロダクタイズされたオファーから始めるべきですか? 一つ。それを構築し、デリバリーし、システムを磨き、推薦文を集め、それから2番目を検討します。同時に2つを立ち上げるほとんどの人は、2つの半分しか構築されていないシステムと、どちらの推薦文もない状態で終わります。 ### 販売を始める前にランディングページが必要ですか? いいえ。最初の5〜10回の販売では、1ページのPDFやよく書かれたメールで十分です。ウェブサイト構築がまだ何も販売していない理由にならないようにしてください。 ### クライアントがスコープ外のものを求めたらどうすればよいですか? それは別のプロジェクトだと伝えます。その場でアドオンを見積もるか、それのためのスコーピングコールをスケジュールします。現在のプロジェクトに吸収しないでください。スコープを守る規律がモデルを機能させるものです。 ### 最初のクライアントをどうやって獲得しますか? あなたの仕事を知る10人にオファーについて話します——あなたを信頼する人や、それを必要としている人を知っている人との温かい会話。最初の販売はほぼ常にランディングページからではなく、直接の会話から来ます。1つのケーススタディができれば、[ファウンダー主導の営業アプローチ](/founder-led-sales-how-to-reach-decision-makers/)がそれをスケールし始めます。 ### 一度だけ行ったことをプロダクタイズできますか? いいえ。まだ本当のスコープを理解していません。カスタム作業としてさらに2〜3回デリバリーし、それからプロダクトに学んだことを正式化します。 --- **次のステップ:** 私の[AI Agents for Beginnersコース](/course/)は、プロダクタイズされたデリバリーをスケーラブルにする自動化システムをカバーしています。[コワークプログラム](/cowork/)は、システム駆動のビジネスを構築し、構造化された環境でそれを行いたいオペレーターのためのものです。 --- ## LinkedInリードジェネレーション戦略:有料広告なしでB2Bクライアントを獲得する方法 Source: https://alejandrorioja.com/ja/linkedin-lead-generation-strategy/ Published: 2026-07-14 Tags: Marketing, Growth, Entrepreneurship TL;DR: LinkedInはB2Bリードジェネレーションにおいて最も高いレバレッジを誇る無料チャネルです。ただし、大量コールドアウトリーチマシンではなく信頼エンジンとして扱う必要があります。プロフィールをランディングページとして最適化し、自分の専門知識の一つの角度で一貫して発信し、価値を先行させる短いアウトリーチシーケンスを構築してください。複利効果は60〜90日で実感でき、その後はほぼ自動的に機能します。有料広告は任意ですが、鋭いプロフィールと有益なコンテンツフィードは必須です。 ## 目次 _2026年7月公開。_ **TL;DR:** LinkedInはB2Bリードジェネレーションにおいて最も高いレバレッジを誇る無料チャネルです。ただし、大量コールドアウトリーチマシンではなく信頼エンジンとして扱う必要があります。プロフィールをランディングページとして最適化し、自分の専門知識の一つの角度で一貫して発信し、価値を先行させる短いアウトリーチシーケンスを構築してください。複利効果は60〜90日で実感でき、その後はほぼ自動的に機能します。有料広告は任意ですが、鋭いプロフィールと有益なコンテンツフィードは必須です。 **オペレーターの視点:** 私はLinkedInを使って、コンサルティングの問い合わせ、コース購入者、パートナーシップの会話を生み出してきました——すべて広告を一切出稿せずに。機能するのはハックやツールではありません。あなたのバイヤーがすでに集まっているスペースで、本物の役に立つ存在として現れることです。これが私が使っている正確なプレイブックであり、今日ゼロから始めるとしたら実行する順序です。 ## 2026年のLinkedInが重要な理由 LinkedInのオーガニックリーチは、ほぼすべての他のプラットフォームよりも高い水準を維持しています。関連性の高いフォロワーを数百人持つ人の投稿でも、数千人のターゲットを絞ったプロフェッショナルにリーチできます——他のほとんどのチャネルでは実際のお金が必要なことです。アルゴリズムは引き続き、単なるいいねではなく、保存やシェアを生む専門知識密度の高いコンテンツを優遇しています。 B2B向けには特に、LinkedInに代わる信頼できる存在はありません: - 意思決定者は他のどのプラットフォームよりもここで連絡が取りやすい。 - インテントシグナルはプロフェッショナル——人々は「仕事モード」にあり、目的なくスクロールしているわけではない。 - コメントや投稿はあなたの思考の公開記録となり、見込み客が数週間または数ヶ月後に見つけられる。 - InMailとコネクション申請は、依然として最も低い獲得コストのアウトリーチメカニズムの一つ。 注意点:LinkedInを価値あるものにしている同じ開放性が、大量アウトリーチ、汎用的なソートリーダーシップ投稿、薄っぺらな売り込みでも溢れています。目立つためのハードルは低いです。ほとんどの人はそれさえもクリアできていません。 ## ステップ1:何かを投稿する前にプロフィールを修正する あなたのLinkedInプロフィールは、見込み客があなたのコネクション申請を受け取ったとき、または書いた投稿に偶然出会ったときに最初に読むものです。誰を助けているか、どのように助けているかをすぐに伝えられなければ、他のすべての行動が損なわれます。 最も重要な4つのポイント: 1. **ヘッドライン** — 役職名ではありません。機能する公式:_[何をする] [誰のために] 彼らが[結果]できるように_。「営業チームなしでB2B SaaSの創業者が最初の10件のエンタープライズ契約を締結するのを支援」は、検索可能で、具体的で、即座に自己資格確認ができます。 2. **バナー画像** — 同じメッセージを強化するために使う。あなたのニッチや短い証明の一文を持つクリーンなビジュアルは、汎用的なグラデーションより優れています。 3. **概要セクション** — 一人称で書く。2つの短い段落:何をする、誰のために、次に1〜2つの証明ポイント(クライアント、結果、成果——本物)。「Xをやろうとしているなら、DMをください」という明確なCTAで締める。 4. **注目セクション** — 1〜2つをピン留め:リードマグネット、最高の投稿、ケーススタディ、予約リンク。ほとんどの人が空白のままにしているプレミアムスペースです。 テスト:見知らぬ人として自分のプロフィールを読む。10秒以内に、何をしているか、誰のためにしているか、次に何をすべきかがわかるか?もしわからなければ、編集を続けてください。 ## ステップ2:一つの角度から、一貫して投稿する 最も一般的なLinkedInの間違いはランダムに投稿することです——月曜日にマーケティングのヒント、水曜日にモチベーションの引用、金曜日に製品のピッチ。アルゴリズムはあなたを無視し、オーディエンスも同様です。 機能するのは、自分の専門知識の一つの特定の角度を選び、それを自分のものにすることです。90日間、週に3〜4回その角度から投稿してください。初期段階では、ボリュームと一貫性が、インスピレーションと磨きを上回ります。 ### 複利効果を生むコンテンツミックス | フォーマット | 用途 | なぜ機能するか | | --- | --- | --- | | 短いテキスト投稿(3〜5行) | 逆張りの見解、クイックフレームワーク、最近の仕事からの教訓 | 高いリーチ、消費の摩擦が少ない、コメントを生む | | リスト投稿 | ステップバイステップの解説、比較、ツール | 保存とシェア;アルゴリズムが好む | | ストーリー投稿 | 直面した具体的な状況、行動、結果 | 他のどのフォーマットよりも速く信頼を築く | | 長文記事 | 深いガイド、エバーグリーンな説明 | 検索でインデックスされ、時間をかけて専門家として位置づける | | カルーセル(ドキュメント) | ビジュアルフレームワーク、長い投稿のまとめ | すべてのフォーマットの中で最高の保存率 | 私が使う比率:70%が短い投稿とリスト、20%がストーリー、10%が長文またはカルーセル。長文投稿はリーチが少ないですが、数ヶ月かけて検索やDMシェアで積み重なります。 ## ステップ3:意図的にコネクションベースを構築する LinkedInで適切なフォロワーを増やすことは、単に数を増やすこととは異なります。正確にあなたのバイヤーである1,000人のフォロワーは、同業者やランダムな観察者である10,000人より価値があります。 私のターゲティング基準: - 私がサービスを提供する業界の意思決定者 - 私が携わる収益規模の企業の創業者とオペレーター - 既存のクライアントや協力者からの二次コネクション(最も温かいソース) - 私のスペースのライバルや同業者と交流している人々 1日に15〜20件のコネクション申請を送り、それぞれに申請する理由を示す1行のメモを添えます。ピッチではなく、ただのコンテキスト:「[トピック]についてのコメントを見ました。私の仕事と関連があります——つながれて嬉しいです。」このメモは承諾率を〜30%(汎用)から〜55〜65%(具体的)に引き上げます。メモは最大2文です。 全員とつながらないでください。資格のないアカウントで膨れ上がったコネクションリストは実際に害を及ぼします——LinkedInのアルゴリズムはあなたの投稿を部分的にあなたのコネクションに配信するため、低品質のオーディエンスはリーチを抑制します。 ## ステップ4:アウトリーチのシーケンスを組む——3タッチアプローチ 誰かがつながったら、すぐにピッチをすることが目標ではありません。時間をかけて会議につながるかもしれない会話を始めることです。コネクションをセールスデッキを貼り付ける許可として扱う人は、その後のすべての接点を台無しにします。 私が使うシーケンス: **タッチ1(1日目、つながりから24時間以内):** 短く温かみのあるウェルカムメッセージを送る。つながった理由に触れ、彼らが共有したものに関連する有益なリソース——投稿、フレームワーク、記事——を共有する。お願いはなし。質問ではなく、陳述で締めくくる。 **タッチ2(5〜7日目):** 彼らの投稿に本物の参加をする——単なるいいねではなく、会話に加わる思慮深いコメント。これにより、別のDMを送ることなく、フィード上で自分の名前を目に見える状態に保つ。 **タッチ3(14〜21日目):** 柔らかく、具体的なお願いでDMをフォローアップする。彼らの仕事で気づいた関連することに結びついた、明確で答えやすい質問。タイミングが合っていて痛みが本物なら、ここで会議が予約されます。そうでなければ先に進んでください——アカウントは温まっており、彼らはあなたの名前を知っています。 私が常に見る間違い:タッチ1と2をスキップして、誰かがつながった瞬間にCTAメッセージに飛びつくこと。それはリードジェネレーションではなく、評判への課税です。 ## ステップ5:会話を会議に変換する DMでの良い会話には、カレンダー招待へのクリーンな出口が必要です。誰かが真の関心を示した瞬間——フォローアップの質問をする、問題を直接述べる、あなたのソリューションに反応する——それがお願いをするときです。 コンバートするメッセージ: > 「[彼らが言った具体的なこと]があなたにとって現実であるように聞こえます。同様の状況にある会社をいくつか支援しました——ピッチなしで、関連性があるかどうかを確認するために、どのようにアプローチしたかを20分で説明しても構いません。[予約リンク]——役立つならスロットを取ってください。」 短く、コミットメントが低く、応じやすい。予約リンクは、本来起こるべき会議の半分を殺すスケジュールの摩擦を排除します。 ## してはいけないこと アカウントが無視され、報告され、またはBANされる原因となる行動: 1. **コンテキストなしの大量コネクション申請** — LinkedInがアカウントを制限し、承諾率が下がります。 2. **ピッチ先行DM** — 最初のメッセージは製品、価格設定、またはカレンダーリンクを紹介する場所ではありません。 3. **エンゲージメントポッド** — 偽のエンゲージメントはバニティメトリクスを膨らませ、アルゴリズム的に罰せられます。 4. **観点なしに毎日投稿する** — 視点のないボリュームはノイズです。週に1つの本物の洞察のある投稿は、週に7つの中身のない「ホットテイク」を上回ります。 5. **アウトリーチを自動化する** — LinkedInのボット検出は積極的になっています。大規模な自動化コネクションツールとAIが書いたDMシーケンスはフラグが立てられます。ステップ4のシーケンスは1日約30分かかり、どのツールも匹敵できないシグナル対ノイズ比を持っています。 ## 本当に重要なことを測定する 無視すべきバニティメトリクス:インプレッション、プロフィール表示数、フォロワー数。 システムが機能しているかどうかを教えてくれる数字: - **コネクション承諾率** — メモ付きで50%以上が目標;30%未満ならメモを書き直す。 - **フォローアップメッセージの返信率** — 適切にターゲットされたリストで20〜30%は健全。 - **1ヶ月あたりの受信DM** — コンテンツのためにあなたに連絡を取ってくる人。月毎に追跡。 - **LinkedInからの1ヶ月あたりの予約通話** — 収益と相関する唯一の数字。 これをシンプルなNotionテーブルで追跡します。最初の90日間の目標は、LinkedInだけから週に1件の受信DM、月に1件の予約通話を達成することです。3ヶ月目には、コンテンツが機能していれば、それらの数字は比例的に多くの努力なしで上昇します。 ## オペレーターの総括 LinkedInがB2Bリードジェネレーションに機能するのは、オーガニックリーチがまだ重みを持ち、評判が時間をかけて公に積み重なる唯一のプロフェッショナルネットワークだからです。メカニクスはシンプルです:誰を助けるかを説明するプロフィール、知識があることを証明するコンテンツ、ピッチではなく価値を先行させるアウトリーチシーケンス。これを90日間一貫して行えば、インバウンドが届き始めます。1年間続ければ、広告予算なしで最も信頼性の高い質の高い会話のソースの一つになります。 --- **関連:** [創業者主導の営業](/founder-led-sales-how-to-reach-decision-makers/) · [個人ブランドの構築方法](/how-to-build-a-personal-brand/) · [アウトリーチ戦略](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) --- ## Courtlines を作った方法:Claude と共に構築した、クラブ運営のためのSaaS Source: https://alejandrorioja.com/ja/how-i-built-courtlines-a-club-management-saas-with-claude/ Published: 2026-07-11 Tags: AI Agents, Case Study TL;DR: Courtlines は、racquetスポーツのクラブやスタジオのためのオペレーティングシステムです。予約、会員管理、コーチング、POS(販売時点管理)、そしてイベントを、一つのブランド化された屋根の下にまとめます。私はこれを、Claude をエンジニアリングパートナーとして、ソロのオペレーターとして作りました。得られた教訓はこうです。AIは私のコーディングを速くしただけではなく、一人の人間が信頼に足る形で世に出し、運営できるプロダクトの規模そのものを変えたのです。 ## 目次 _2026年7月更新。_ **要点:** Courtlines は、racquetスポーツのクラブやスタジオのためのオペレーティングシステムです。予約、会員管理、コーチング、POS(販売時点管理)、そしてイベントを、一つのブランド化された屋根の下にまとめます。私はこれを、Claude をエンジニアリングパートナーとして、ソロのオペレーターとして作りました。得られた教訓はこうです。AIは私のコーディングを速くしただけではなく、一人の人間が信頼に足る形で世に出し、運営できるプロダクトの規模そのものを変えたのです。 **[オペレーターの視点]** 私はコンサルティングブランドと、テキサス州オースティン都市圏で運営するピックルボール施設 Pickleland にまたがって、30以上の本番稼働エージェントを走らせています。実際に施設を運営してみて、私のようなクラブ向けのソフトウェアがいかにひどいかを、身をもって学びました。だから私は、自分が欲しかったソフトウェアを自ら作ったのです。これは [Courtlines](https://courtlines.com) の物語であり、それが何をするのか、そして Claude に頼ることで、いかにして一人の人間が通常ならチームを要するものを作り上げられたのかについての話です。 ## なぜクラブには「アプリ」ではなく「オペレーティングシステム」が必要なのか スポーツ施設を運営したことがなければ、ソフトウェアの問題は目に見えません。外から見れば「人がコートを予約する」ように見えます。しかし内側から見れば、クラブとは、互いに整合していなければならない十数個の可動パーツを抱えた、小さくて雑然としたビジネスなのです。 会員がコートを予約する。その予約は、その人が会員プランに入っているかどうか、クレジットを持っているかどうか、そのコートがすでにクリニック用に押さえられていないか、コーチが割り当てられているか、そしてフロントデスクが料金を上書きしていないかを、すべて把握していなければなりません。会員が来店すると、誰かがカウンターでボールの缶を精算する。それがPOSです。子どもをジュニアプログラムに申し込む。それがイベントと家族アカウントです。レッスン10回パックを買う。それはコーチング・パッケージであり、コーチへの独自の支払いロジックを伴います。友人を紹介する。それが会員獲得のファネルです。 ほとんどのクラブは、これを3つか4つのバラバラなツールと、スプレッドシートと、グループチャットで回しています。予約システムはPOSのことを知りません。POSは会員管理のことを知りません。月末には、誰の数字も一致しないのです。 **Courtlines は「もし、それらすべてが一つのシステムだったら?」という問いへの答えです。** これは、機能を後付けした予約アプリではありません。カレンダー、会員管理、レジ、コーチングの支払い、そして公開イベントページのすべてが、同じ基盤データである、単一のオペレーティングシステムです。それがこのプロダクト全体の主張であり、サイトのキャッチコピーそのものです。クラブとスタジオのためのオペレーティングシステム、と。 ## Courtlines が実際にできること 大まかに言えば、[Courtlines](https://courtlines.com) はクラブに次のものを提供します。 - **ドラッグ&ドロップのコートグリッド** ── フロントデスク向けに、すべての予約、クリニック、押さえを一画面にまとめ、管理者がリアルタイムで並べ替えられます。 - **予約とオープンプレイ** ── 会員向けに、面倒だが不可欠なエッジケースも含めて。繰り返し予約、キャンセル待ち、キャンセル可能な期間、そしてクレジット。 - **会員管理と請求** ── プラン、家族アカウント、親にひも付いたジュニア/子ども用ログイン、そして収益が静かに漏れ出すのを防ぐ督促(ダニング)処理。 - **コーチング** ── レッスンパッケージ、スケジューリング、そして独立コーチへの自動支払い。 - **POS(販売時点管理)** ── プロショップとカフェのための本物のレジで、他のすべてと同じ顧客記録にひも付いています。 - **イベントと公開ページ** ── クリニック、リーグ、トーナメントを、人々が見つけて申し込める公開ページとともに。 設計上の目標は、プラットフォームが「消える」ことです。クラブが自分のブランドを上にかぶせれば、会員にとってそれは単に「うちのクラブのアプリ」に感じられ、「うちが料金を払っているどこかのSaaS」には感じられません。これは、この分野の既存プレイヤー ── CourtReserve や Skedda のような存在 ── との意図的な対比です。彼らのソフトウェアではソフトウェアこそがブランドであり、クラブは間借りするテナントに過ぎません。 Pickleland はテナント第1号です。私はデモの裏に隠れることはできません。この製品は、私自身が個人的に責任を負う施設を、実際に動かさなければならないのです。その制約こそが、私がこれまで持ったなかで最高のプロダクトマネージャーでした。[Pickleland はこちらで見られます](https://pickleland.com)。それは現実世界の実証の場であり、会員がぶつかるすべての粗い部分は、私がその日のうちに感じるバグなのです。 ## 私を驚かせた部分:今や一人のオペレーターが世に出せるもの ここからが、この物語の正直な版です。そして、ひっそりと立ち上げるのではなく、この記事を書いている理由でもあります。 請求、POS、ロールベースのアクセス制御、コーチングの支払い、そして公開イベントシステムを備えたマルチテナントSaaSは、週末プロジェクトではありません。10年前なら、これはシードで資金調達した5〜8人のエンジニアチームが1年がかりで取り組む規模です。ソロの創業者なら、たいてい親切に「一つの機能に絞って、資金を集めなさい」と言われるような規模なのです。 私はこれを、**Claude を主要なエンジニアリングパートナーとして**、一人で作りました。「ときどき ChatGPT にコード片を尋ねた」という意味ではありません。私が所有する仕様とプロダクト上の決定に基づいて、Claude がこのシステムのコードの大半を書いた、という意味です。私の仕事は「実装を打ち込むこと」から「何が正しいかを決めること」へと移りました。データモデルはどうあるべきか、あるロールに何が許されるか、ある機能にとって「完成」とは何を意味するか、そして何を安全に世に出せるか、を決めることへと。 興味深い変化は、速さではありません ── たしかに速くはなりますが。それは**規模**です。AIは、同じ規模のプロダクトで私を2倍の開発者にしたのではありません。それは、私が信頼に足る形で作れる、そして同じくらい重要なことに、一人で*運営し保守できる*プロダクトの規模を変えたのです。たった一人の人間が書いたコードベースは、自らの重みで崩壊してしまいます。AIパートナーが実装の詳細を保持し、私がアーキテクチャとガードレールを保持するコードベースは、まったく別種のものです。そしてそれこそが、かつては会社を必要としたカテゴリーに、いまソロのオペレーターが挑めるようになった理由なのです。 私はここで、Courtlines のための正確な運営プレイブックをあえて公開しません。それは私が競争優位だと考えている部分であり、競合には「これには大きなチームが要る」と信じ続けてもらったほうがいいのです。しかし、私が実際のプロジェクトで Claude をどう回しているのか、その*仕組み*を詳しく見たいのであれば、はるかに小さなビルドについてはすべて書き起こしました。アプリストアに出したモバイルゲームです。[Quads というモバイルボードゲームを、Claude とどう作ったか](/how-i-built-quads-a-mobile-board-game-with-claude/) をご覧ください。同じ働き方で、隠すものは何もなく、手の内をすべてさらしています。 ## 私が譲らない原則 プレイブックは非公開のままでも、いくつかの原則は述べておく価値があります。AIで本格的なソフトウェアを作るすべての人に当てはまるからです。 **危険なペンは人間が握る。** 間違いが高くつき、取り返しがつきにくい行為は、ごく少数存在します。スキーマ変更、デプロイ、そして金銭や本番データに触れるものすべてです。それらは断固として私の手に残します。AIはそれらを提案できますが、実行はできません。その一線を明確に引くことこそが、それ以外のあらゆる場面でAIに大きな裁量を与えても安全でいられる理由なのです。 **テストが緑なのは必要条件であって、十分条件ではない。** すべてのユニットテストを通過する予約フローが、実際のブラウザでは目に見えて壊れていることがあります。UIを持つプロダクトにとって最も重要な検証は、人間 ── あるいは監督されたプロセス ── が、現実的なデータに対して実際にクリックして回ることです。テストは物事が悪化するのを防ぐ勾配であって、機能が動く証明ではありません。私はこれを高い授業料を払って学び、それが「完成」の定義を永久に変えました。 **仕様こそが本当のインターフェースだ。** てこの力は巧妙なプロンプトにあるのではなく、システムが何であり、各パーツが何をするはずなのかについて、明確で最新のドキュメントを維持することにあります。それらを正確に保つために費やした時間は、その後のすべてのセッションにわたって、何倍にもなって返ってきます。この深掘り版が欲しければ、[本番で失敗しないAIエージェントのシステムプロンプトの書き方](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/) で述べているのと同じ規律です。 **自分が付き合わなければならないものを作れ。** 最良の決断は、Courtlines に自分が所有する施設を運営させたことでした。人を感心させるデモを出すのは簡単ですが、自分自身の会員が頼りにするソフトウェアから逃げることは不可能です。AIで何かを作るなら、自分が個人的に感じている問題に向けなさい。その現実によるチェックは、どんなテストスイートよりも価値があります。 ## これが、私が作っている他のすべてとどう噛み合うか Courtlines は孤立して存在しているわけではありません。それは私が構築している小さなracquetスポーツのエコシステムの一部です。[The Court Scout](https://thecourtscout.com) は、ピックルボールコートを検証済みで掲載するディレクトリで、競合するスクレイピング型のディレクトリよりも本当に正確であるように作られています。そして Pickleland は、すべてがそれに対してテストされる旗艦施設です。ディレクトリはプレイヤーがコートを見つけるのを助け、Courtlines はそれらのコートの背後にあるクラブが実際に運営するのを助けます。 そのすべてを貫く結合組織は、同じ運営モデルです。AIによって増幅されたソロのオペレーターが、歴史的にソロのオペレーターが扱えたよりも大きな面積を回す、というモデルです。Courtlines は、このモデルのこれまでで最も野心的な表現です ── 数年前なら、私が一人で挑もうとは到底思わなかったであろう、フルのSaaSプラットフォームなのです。 もしあなたがracquetスポーツのクラブやスタジオを運営していて、4つのツールをつなぎ合わせることにうんざりしているなら、[Courtlines](https://courtlines.com) を覗いてみてください。そして、もしあなたが、実際のプロダクトでAIをどこまで押し進められるのかと考えている作り手なら、それこそがこの記事の全趣旨です。おそらくあなたが思うより、ずっと遠くまで押し進められます。 ## FAQ ### Courtlines とは何ですか? Courtlines は、racquetスポーツのクラブやスタジオ ── ピックルボール、テニス、パデル、そしてそれ以外 ── のためのマルチテナントのオペレーティングシステムです。予約、会員管理、コーチング、POS、そしてイベント管理を、一つのブランド化されたプラットフォームにまとめます。だからクラブは、4つのバラバラなツールではなく、単一のシステムからビジネス全体を運営できます。[courtlines.com](https://courtlines.com) でご覧いただけます。 ### 本当に Claude がコードの大半を書いたのですか? はい。Claude は私の主要なエンジニアリングパートナーであり、私が所有し統制する仕様、アーキテクチャ、プロダクト上の決定に基づいて、実装の大半を書きました。私はスキーマ、デプロイ、そして「完成」の定義を握り、AIは実装の詳細を握ります。その分業こそが、この規模のソロビルドSaaSを、持続的に保守可能にしているのです。 ### AIを使えば、本当に一人でこれほど大きなSaaSを作って運営できるのですか? 作ること自体は、いまや本当に実現可能です ── そこが驚くべき部分です。より大きな課題は、それを運営し保守することです。なぜなら、大きなコードベースには、たとえAIが詳細を書いたとしても、アーキテクチャを理解している人間が必要だからです。鍵は、明確な仕様を保ち、人間が所有しなければならないごく少数の高リスクな行為について、断固たる姿勢を崩さないことです。そのように進めれば、一人のオペレーターが保守できる面積は、かつてよりもはるかに大きくなります。 ### CourtReserve や Skedda を使わず、なぜ自前のクラブソフトを作るのですか? Pickleland を運営したことで、既存のツールがどこで力尽きるのかが、まさに明確に見えたからです。予約システム、レジ、会員管理が一つの真実の源を共有していないので、何一つきれいには帳尻が合いません。私は、そのすべてが同じ基盤データであり、会員が目にするのがソフトウェアベンダーではなくクラブのブランドである、そんなシステムが欲しかったのです。それが、Courtlines が埋めるために作られたギャップです。 ### あなたが日々どのように Claude と働いているのか、どこで学べますか? Courtlines の詳細なプレイブックは競争上の理由で非公開にしていますが、まったく同じ働き方を、より小さくて完全にオープンなプロジェクトで記録しました。Quads というモバイルボードゲームです。その仕組みについては [Quads というモバイルボードゲームを、Claude とどう作ったか](/how-i-built-quads-a-mobile-board-game-with-claude/) を、そして私が世に出すすべての背後にあるROIの考え方については [ある自動化に作る価値があるかをどう判断するか](/ai-agent-roi-how-i-decide-whether-automation-worth-building/) をお読みください。 --- ## Quads というモバイルボードゲームを、Claude と作った方法 ── 2時間のハッカソンから App Store まで Source: https://alejandrorioja.com/ja/how-i-built-quads-a-mobile-board-game-with-claude/ Published: 2026-07-11 Tags: AI Agents TL;DR: Quads はモバイルボードゲームで ── 古典的な抽象ゲーム Quarto をすっきりと作り直したものです ── コロンビアで友人と行った2時間のハッカソンから始まり、アプリストアに出荷されました。これは、私が Claude とどう作るかを完全にオープンにした版です。並列のエージェント worktree、本物の(LLMではない)ゲームAI、オフラインファーストの設計、そして私に時間を費やさせた具体的な落とし穴について。 ## 目次 _2026年7月更新。_ **要点:** Quads はモバイルボードゲームで ── 古典的な抽象ゲーム Quarto をすっきりと作り直したものです ── コロンビアで友人と行った2時間のハッカソンから始まり、アプリストアに出荷されました。これは、私が Claude とどう作るかを完全にオープンにした版です。並列のエージェント worktree、本物の(LLMではない)ゲームAI、オフラインファーストの設計、そして私に時間を費やさせた具体的な落とし穴について。 **[オペレーターの視点]** 私はコンサルティングブランドと、オースティン都市圏のピックルボール施設 Pickleland にまたがって、30以上の本番稼働エージェントを走らせています。私が作るものの大半は本格的なビジネスソフトウェアで、そこではプレイブックを非公開にしています。Quads はその逆です ── 頭からお尻まで見せられる、楽しいサイドプロジェクトです。私が Claude とどう働いているのかを、何一つ削らずにそのまま見たいなら、これがその記事です。ゲームは [playquads.com](https://playquads.com) にあります。 ## それはコロンビアでの2時間のハッカソンから始まった その始まりは、ほとんど気恥ずかしいほど気軽なものでした。私はコロンビアへの旅の途中で、友人と二人で自分たちに2時間のハッカソンを課しました。小さな何かを選び、AIで作り、どこまで行けるか見てみよう、と。私たちは Quarto に落ち着きました ── 覚えやすく、しかし驚くほど奥深い、美しく小さな抽象戦略ゲームです。2時間後には遊べるプロトタイプが手元にあり、そのアイデアはノートパソコンに置き去りにするには惜しすぎました。 時間を区切った挑戦として始まったものが、iOS と Android で実際に出荷されたモバイルアプリになったのです。その軌跡 ── *冗談のプロトタイプからストアの掲載へ* ── こそが、このプロジェクトを書き記す価値があると私が考える、まさにその理由です。「楽しいアイデア」と「見知らぬ人がダウンロードできるもの」の間の距離は縮まりました。そして Quads は、その縮まり方の見事なケーススタディなのです。 まず、名前について少し寄り道を。このゲームは **Quarto** の再実装ですが、Quarto は Gigamic が所有する商標登録済みのゲームです。だから、コードに関わらない最初の決定は、顧客の目に触れるところではどこでも Quarto と*呼ばない*ことでした。Quarto(メカニズム)から、いくつかの暫定的な名前を経て、**Quads** ── 私が自由に使える名前 ── へと落ち着きました。古典を再実装するなら、名前に惚れ込む前に商標の問題を片付けておきなさい。 ## Quads とは実際に何なのか 知らない人のために。Quads は4×4のボードと16個のユニークな駒で遊びます。すべての駒は4つの二値属性を持ちます ── 高いか低いか、濃いか薄いか、四角いか丸いか、中実か中空か ── そして16個の駒が、あらゆる組み合わせをちょうど一度ずつ網羅します。*いずれか一つ*の属性を共有する駒4つの列を完成させると勝ちです。 これを見事にする仕掛けはこうです。**あなたは自分が置く駒を選べません。相手があなたに手渡すのです。** そして今度はあなたが相手の駒を手渡します。だから毎ターンが二重の板挟みです ── 手渡された駒を、勝ちの布石にならないように置こうとしながら、相手に勝ちを差し出さない駒を選んで渡そうとするのです。エレガントで、本当に難しい。 このアプリは、すべて完全にオフラインで動く4つの遊び方を備えています。5段階の難易度でコンピューターと対戦、一台の端末でパス&プレイ、デイリーパズル、そして非同期の「友達に挑戦」モード。アカウントなし、サーバーなし、ログインなし。そのオフラインファーストの決定が、エンジニアリングの多くを方向づけました。そして、それがソロビルドを扱いやすくした大きな理由でもあります。 ## ゲームロジック:ビット演算からこぼれ落ちるルールセット全体 ここが私のお気に入りです。なぜなら、AIが書いたかどうかに関わらず満足できる類のものだからです。 16個の駒はそれぞれ、0から15までの単なる整数です。4つのビットのそれぞれが一つの属性です。それだけです ── 駒のセット全体が 0〜15 の数字なのは、4ビットがちょうど16通りの組み合わせを与えるからです。 すると勝ち判定は、ほとんど自明になります。任意の4つの駒の列について、二つの累算器を回し続けます。*すべての*駒で `1` であるビットと、*すべての*駒で `0` であるビットです。4つすべての後にどちらかの累算器がゼロでなければ、それらの駒は少なくとも一つの属性で一致しています ── それが勝ちです。ルールセット全体が、ほんの数個のビット単位のANDに収束するのです。 このロジックは整数上の純粋関数だからこそ ── フレームワークなし、UIなし、状態なし ── 直接ユニットテストが可能で、拡張も容易です。Quads には、9個の2×2の正方形も勝ちの形として数えるハウスルールのバリアントさえ搭載されていますが、それは同じビットの仕掛けの上に2行を足すだけの追加です。あなたとAIパートナーがコアロジックをこれほどきれいに保つと、機能を追加することはリスクではなく喜びになります。 ## AIの対戦相手は LLM ではない(そしてそれが正しい判断だ) ここに、私が大切にしている学びの瞬間があります。**すべての「AI」が大規模言語モデルであるべきではありません。** Quads の対戦相手は純粋な古典的ゲームAIで、そうあるべきなのです。毎ターン、それは二つの決定を下します ── 手渡された駒をどこに置くか、そしてどの駒を返すか ── そして難易度が、どれだけ深く考えるかを調整します。 - **ルーキー**は本質的にランダムに打ち、あなたに勝ちを手渡します。 - 中間の難易度はヒューリスティックを加えます。即座の勝ちがあれば取り、相手が勝てる駒を贈るのを避け、未来の脅威を最も少なくする駒を優先して渡します。 - **マスターとグランドマスター**は、範囲を制限した negamax 探索 ── 本物のゲーム木探索 ── を走らせますが、一手が決して端末のメインスレッドをハングさせないように、厳しい**ノード予算**を設けています。完全な探索が手に負えないゲーム序盤では、高速なヒューリスティックにフォールバックし、木が十分に小さくなる終盤では、本当に探索します。 ここから盗む価値のあることが二つあります。第一に、ここでは言語モデルは*より劣る*でしょう ── 50行の negamax よりも、遅く、高価で、非決定的で、しかも打ち負かせる。ツールを問題に合わせなさい。第二に、ノード予算こそが本当のエンジニアリングです。モバイル端末では、「正しいが時々4秒間ハングする」は失敗した機能です。一手が常に高速であるように ── たとえ時々最適でなくとも ── 探索を制限することこそが、おもちゃとプロダクトの違いなのです。*いつ* LLM に手を伸ばすべきかを知ることは、私がすべての自動化に適用する判断と同じものです ── それが [あるAIビルドに価値があるかをどう判断するか](/ai-agent-roi-how-i-decide-whether-automation-worth-building/) の核心です。 ## 私が実際にどう Claude を回すか:worktree の中の並列エージェント さて、より大きなプロダクトでは非公開にしているが、ここでは完全にお見せできる部分です。 私は一度に一つの Claude セッションで作ることはしません。**複数を並列で**走らせます。それぞれが自分の git worktree の、自分のブランチの中にいます。あるエージェントは国際化を追加し、別のエージェントはデイリーパズルのシステムを作り、また別のエージェントは色覚多様性モードをやり、さらに別のエージェントはサウンドを配線する ── それぞれが自分の作業コピーの中で隔離されているので、互いに上書きし合うことがなく、それぞれが緑になったらマージして戻します。Quads の git 履歴は `Merge branch 'worktree-agent-…'` というコミットの壁で、それはまさに、そのワークフローを外から見たときの姿です。 worktree が重要な理由は単純です。同じ作業ディレクトリを編集する並列エージェントは、即座に互いを踏みつけます。それぞれに隔離されたチェックアウトを与えれば、本当に4つの機能を同時に建設中にでき、それから他のブランチと同じようにマージできます。それは私の働き方に対する、単一で最もてこの効く変更でした ── 私は「一つの会話、一つの機能」から、小さな艦隊へと移行したのです。 それらのエージェントが走るプロンプトの背後にある規律が欲しければ、[本番で失敗しないAIエージェントのシステムプロンプトの書き方](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/) で述べているのと同じものです。てこの力は、明確で最新の仕様にあるのであって、巧妙な言い回しにあるのではありません。 ## 私に1時間を費やさせた落とし穴(だからあなたには費やさせない) どのプロジェクトも、一つの、ばかげていて、高くつく教訓を教えてくれます。Quads では、それはこうでした。**プレビューツールは、あなたが表示していると思っているブランチを、必ずしも表示していない。** 複数の worktree で複数のエージェントを走らせ、その作業をプレビューすると、プレビューは現在のセッションがいるディレクトリとは*別の*ディレクトリから起動することがあります ── だからアプリのスクリーンショットを撮っても、変更が何一つ見えず、そもそも欠けてなどいなかった「欠けた」UIをデバッグし始めてしまうのです。機能は問題なく、プレビューが間違ったチェックアウトを指していただけでした。何が起きているのか気づくまでに、私は本当に時間を失いました。そして、未来の自分(と、私がリポジトリを手渡すあらゆるエージェント)が、幻のバグをデバッグする*前*にプレビューの対象を確認できるよう、プロジェクト自身のノートに書き留めました。 関連する罠。それらのプレビューを定義する設定ファイルは、並列セッション間で共有されているので、二つのエージェントが同時にそれを編集すると、静かに互いのエントリを上書きし合うことがあります。艦隊を走らせるつもりなら、共有設定は競合するリソースとして扱いなさい ── それはちょうど一度だけあなたに噛みつき、教訓を書き留めれば二度と噛みつきません。 その習慣 ── 苦労して得たすべての落とし穴を、次のセッションが読む永続的なファイルに捉えること ── は、あらゆる規模でAIと共に作ることの、静かな背骨です。文脈はセッション間で蒸発しますが、書き留められた教訓は蒸発しません。 ## 私が誇りに思うオフラインファーストの工夫 Quads にはバックエンドがないので、いくつかの問題には巧妙でサーバーレスな答えが必要でした。 - **デイリーパズル**は、ローカルの「年の何日目か」から決定論的に選ばれるので、世界中のすべてのプレイヤーが、サーバーの調整をまったく必要とせずに同じパズルを得ます。(おまけの教訓。私はその日付の計算にサマータイムの off-by-one を出荷し、すぐに直しました。日付は、いつも見た目より難しいのです。) - **「友達に挑戦」**は、パズルを短いテキストコード ── `QC1-01-03-3` のようなもの ── にエンコードし、チェックサムで守ることで、打ち間違いが「有効だが間違った」挑戦を生み出せないようにしています。あなたの友達は自分のアプリのコピーにそれを打ち込み、まったく同じ局面を、完全にオフラインでプレイします。アカウントなし、マッチメイキングなし、サーバーなし。 - **リッチなリンクプレビュー**は、私がほんの少しだけサーバーコードを使った唯一の場所です。挑戦のリンクを共有すると、単一の Cloudflare Pages Function がコードごとの Open Graph タグをレンダリングし、リンクが iMessage や WhatsApp できれいに展開されるようにします。ソーシャルのクローラーは JavaScript を実行しないので、クライアントでレンダリングしたプレビューはどのリンクでも同じに見えてしまいます ── 一つの小さな関数が、本物のバックエンドを必要とせずにそれを直します。 これらはどれも、一度見てしまえば難しくありません。しかしそれぞれが、怠けた答えが「サーバーとデータベースを立ち上げる」であり、より良い答えが「巧妙なオフラインのやり方をする」である場所なのです。バックエンドを完全に避けたことこそが、一人でこれを出荷し保守できた理由です。 ## ハッカソンからストアの掲載へ 最後の道のり ── 「2時間プロジェクト」について誰も教えてくれない部分 ── は、「自分のスマホでは動く」と「見知らぬ人がダウンロードできる」の間のすべてです。8言語にわたる国際化を一気に。商標名を決して使わないストアの説明文。アプリストアのビルドツール、バージョン管理、そしてストア審査に跳ね返されないためのプラットフォーム固有の権限の整理。これは華やかさに欠け、そして多くのサイドプロジェクトが静かに死んでいく場所です。 それを Claude と共にやっても、チェックリストが短くなったわけではありません。しかし、各項目を、私が実際にやり遂げられるほど安くしてくれました。それが Quads の本当の物語です。AIがボードゲームを書いたということではなく ── プロトタイプなら多くの人が作れます ── AIが*ラストマイル*のコストを、ハッカソンの冗談が出荷済みのプロダクトになるほどに下げた、ということなのです。 温めてきた小さなアイデアがあるなら、それが私の売り込みのすべてです。まずは2時間版を始めなさい。ゴールラインがどれほど近づいたか、驚くはずです。そして、この同じ働き方がスケールのどこまで上まで通用するのかを見たければ、私はそれをフルのマルチテナントSaaSまで押し進めました ── [Courtlines というクラブ運営プラットフォームを、Claude とどう作ったか](/how-i-built-courtlines-a-club-management-saas-with-claude/) です。 Quads は [playquads.com](https://playquads.com) でプレイできます。 ## FAQ ### Quads とは何ですか? Quads は iOS と Android 向けのモバイルボードゲームで ── 古典的な抽象戦略ゲーム Quarto をすっきりと再実装したものです。4×4のボードと16個のユニークな駒で遊び、その仕掛けは、あなたが置かなければならない駒を相手が選ぶ、という点にあります。無料で遊べ、ソロ、パス&プレイ、デイリーパズル、そして非同期の挑戦モードを備えています。[playquads.com](https://playquads.com) で見つけられます。 ### Claude がゲーム全体を書いたのですか? Claude はコードの大半を、私が所有する設計と決定に基づいて書きました。私は複数の Claude セッションを並列で走らせ、それぞれを自分の git worktree の中に置き、異なる機能を作らせては、それらをマージしてまとめました。ゲームロジック、AIの対戦相手、国際化、サウンド、そしてパズルのシステムは、大部分がこの方法で作られ、私がレビューしました。 ### ゲーム内のAIの対戦相手は LLM で動いているのですか? いいえ ── そして、それは意図的です。対戦相手は古典的なゲームAIを使っています。低い難易度ではヒューリスティックを、最上位の難易度では範囲を制限した negamax 探索を、そして一手が決して端末をハングさせないよう厳しいノード予算を伴って。言語モデルは、この仕事には遅く、高価で、しかも弱いでしょう。問題に対して正しい種類のAIを選ぶことは、いつも最大のモデルに手を伸ばすことよりも重要なのです。 ### Quads を作るのにどれくらいかかりましたか? 最初の遊べるプロトタイプは、コロンビアへの旅で友人と行った2時間のハッカソンから生まれました。そのプロトタイプを、両方のアプリストアで磨き上げられた出荷可能なアプリにすること ── 国際化、本物のAIの対戦相手、オフラインの挑戦、そしてストアのコンプライアンスを備えて ── には、かなり長くかかりました。しかし個々のステップは、AIと共にやれば、プロジェクトが実際にゴールラインに到達するほど安く済んだのです。 ### Quads を Claude と作って得た最大の教訓は何ですか? 二つあります。第一に、エージェントを隔離された git worktree の中で走らせること。そうすれば、互いに上書きし合うことなく、複数の機能を並列で作れます。第二に、すべての落とし穴を、次のセッションが読む永続的なファイルに書き留めること ── 文脈はセッション間で蒸発しますが、書き留められた教訓は積み重なります。この働き方のより大きな全体像については、[Courtlines を Claude とどう作ったか](/how-i-built-courtlines-a-club-management-saas-with-claude/) をご覧ください。 --- ## 本番環境で失敗しないAIエージェント・システムプロンプトの書き方 Source: https://alejandrorioja.com/ja/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/ Published: 2026-07-11 Tags: AI Agents TL;DR: 本番環境のシステムプロンプトには5つのレイヤーがある:アイデンティティ(エージェントが誰で何をしてはいけないか)、コンテキスト(環境について何を知っているか)、タスク(成功がステップごとにどう見えるか)、出力フォーマット(最も過小評価されているレイヤー)、エッジケース(入力が失敗したときの対処法)。ほとんどのプロンプトはレイヤー4と5を省略するから失敗する。出力フォーマットを最初に書くことで、本当に何が欲しいかを正確に考えることができる。 ## 目次 _2026年7月更新。_ **TL;DR:** 本番環境のシステムプロンプトには5つのレイヤーがある:アイデンティティ(エージェントが誰で何をしてはいけないか)、コンテキスト(環境について何を知っているか)、タスク(成功がステップごとにどう見えるか)、出力フォーマット(最も過小評価されているレイヤー)、エッジケース(入力が失敗したときの対処法)。ほとんどのプロンプトはレイヤー4と5を省略するから失敗する。出力フォーマットを最初に書くことで、本当に何が欲しいかを正確に考えることができる。 **[オペレーターの視点]** 私はコンサルティングブランドとPickleland(テキサス州プフルーガービルのピックルボール施設)で30以上のAIエージェントを本番稼働させている。書いたシステムプロンプトより書き直したものの方が多い。最初のバージョンはテストでは良さそうに見えて、本番では静かに劣化するのが常だ。これは、長持ちするプロンプトの書き方について学んだことだ。 ## 誰も認めないシステムプロンプトの問題 ほとんどのエージェント・システムプロンプトは約20分で書かれ、2〜3の例でテストされ、その後二度と触られない。モデルはリリースされる。しばらくはうまくいく。そして何かが変わる——入力がより乱雑になり、モデルが更新され、新しいエッジケースが現れる——エージェントはガベージを生成し始める。静かに。スケールして。 問題は元のプロンプトが悪かったわけではない。ほとんどのプロンプトはハッピーパスを実証するために書かれている。エージェントを構築したときに想定していた入力のために設計されており、エージェントが実際に見る入力の完全な分布のためではない。 ## 本番システムプロンプトの5つのレイヤー 私が書くすべてのシステムプロンプトを5つのレイヤーで考える。この順序で表示される必要はないが、すべて存在しなければならない。 ### レイヤー1:アイデンティティ アイデンティティは、モデルに自分が誰で、どんな運用上の制約があるかを伝える。ロールプレイキャラクターではなく、このエージェントが何をして何をしないかの機能的定義だ。 強いアイデンティティレイヤーは3つの質問に答える: - このエージェントは何に責任を持つか? - 明示的に責任を持**ない**のは何か(エスカレートするか拒否すべきか)? - どんな基準を守るか? 「しない」スコープの明示的な部分は、ほとんどのオペレーターが省略する部分だ。それがないと、モデルは管轄外で役に立とうとする——そしてそこで問題が起きる。 ### レイヤー2:コンテキスト コンテキストは、ユーザーのメッセージにはないが、エージェントが自分の環境について知っていることだ。これには現在の日付と時刻(動的に注入する——モデルの内部時間感覚は信用しない)、外部システムからの関連状態、タスクの説明からは明らかでないビジネスルールが含まれる。 私がレビューするほとんどのエージェントはコンテキストが不足している。想定するな。注入せよ。 ### レイヤー3:タスク タスクレイヤーはエージェントが何をステップごとに行うかを記述する。「顧客を助ける」ではなく——実際の意思決定フローだ。指示としてではなくフローチャートとして書く。フローチャートの方が堅牢で、あいまいなケースでモデルが何を望んでいるか推測する必要が減る。 ### レイヤー4:出力フォーマット これが最も過小評価されているレイヤーで、サイレントな失敗に最も責任があるものだ。 出力フォーマットを正確に指定しないと、モデルは人間の読者には正しく見えるが、下流の解析を壊すほど一貫性のない出力を生成する。出力フォーマットを最初に書く。構造化出力には正確なスキーマを指定する。散文出力には構造、長さ、トーンの制約を指定する。 高リスクのエージェントには、定義されたJSONスキーマで[Claude](/recommends/claude)の構造化出力を使用する。 ### レイヤー5:エッジケース エッジケースレイヤーは答える:入力があいまい、不完全、間違った言語、敵対的、または明らかに間違っている場合にエージェントは何をするか?各エッジケースに対して、明示的な応答パスをモデルに与える。 ## 時間をかけてシステムプロンプトをどうメンテナンスするか 本番システムプロンプトは生きたドキュメントだ: 1. **週次スポットチェック。** 各高リスクエージェントの5〜10のランダムな出力を期待される出力と照らし合わせてレビューする。 2. **モデルアップデート後のレビュー。** 基盤モデルのバージョンが変わるたびに、[評価フレームワーク](/how-i-measure-whether-an-ai-agent-is-actually-working/)のゴールデンセット全体に対してエージェントを実行する。 3. **エッジケースログ。** エージェントがうまく処理できなかった入力の継続的なログを維持する。3つ以上のエントリがパターンを共有する場合、明示的なルールを追加する。 4. **プロンプトバージョニング。** 重要な変更はすべてプロンプトファイルの先頭にバージョンコメントを付ける。 ## よくある質問 ### 本番システムプロンプトはどのくらいの長さにすべきか? 5つのレイヤーをすべてカバーするのに十分な長さ。2分で読んでドリフトを見つけられるほど短い長さ。ほとんどのエージェントで200〜600ワードだ。 ### 複数のエージェントに分割すべきのはいつか? タスクに、異なるコンテキスト、異なる出力フォーマット、または異なるエラー処理を必要とする2つ以上の明確に異なるモードがある場合。パターンについては[イベントトリガーと定期実行エージェント](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/)を参照。 ### テストで機能したプロンプトが本番で失敗する最も一般的な理由は何か? テスト入力が本番の分布を代表していなかった。想像上の入力ではなく、実際の本番トラフィックからテストセットを構築する。 ### プロンプトとコードのどちらを更新すべきかをどう判断するか? エージェントが間違った出力フォーマットを生成している場合はプロンプトを更新。エージェントが正しい出力を生成しているが下流システムが使えない場合はコードを更新。エージェントが自信を持って間違った事実を生成している場合はまずコンテキストレイヤーを確認する。 --- ## AIエージェントのROI:自動化を構築する価値があるかどうかの判断方法 Source: https://alejandrorioja.com/ja/ai-agent-roi-how-i-decide-whether-automation-worth-building/ Published: 2026-07-09 Tags: AI Agents, Operations TL;DR: AIエージェントを構築する前に、4段階のROIチェックを行います:手動コストの定量化、構築コストの見積もり、運用コストの予測、メンテナンス税の追加。結果は回収期間です。非戦略的タスクで6ヶ月を超える場合は中止します。ほとんどのエージェントアイデアはこのテストに失敗します——それが重要なのです。間違った自動化を構築することは、何も構築しないよりも悪いことです。 ## 目次 _2026年7月更新。_ **TL;DR:** AIエージェントを構築する前に、4段階のROIチェックを行います:手動コストの定量化、構築コストの見積もり、運用コストの予測、メンテナンス税の追加。結果は回収期間です。非戦略的タスクで6ヶ月を超える場合は中止します。ほとんどのエージェントアイデアはこのテストに失敗します——それが重要なのです。 **【オペレーターの視点】** 私はコンサルティングブランドとPickleland(テキサス州プフルーグビルのピックルボール施設)を通じて、本番環境で30以上のAIエージェントを運用しています。立ち上げたエージェントと同じくらい多くのエージェントを中止してきました。中止したものは悪いアイデアではありませんでした——数学のテストに合格しなかった良いアイデアでした。 ## 誰も最初に聞かない質問 2026年、誰もが「これをどう自動化するか?」と聞いています。より良い質問は「これを自動化すべきか、そしていつ回収できるか?」です。 AIエージェントは無料ではありません。構築に時間がかかり、実行にお金がかかり、維持に継続的な注意が必要です。自動化が手動の代替手段よりも早くそれらのコストを回収できなければ、オペレーションをより複雑でコストがかかるものにしているだけです——より効率的ではありません。 ## ステップ1:手動ベースラインの定量化 最初の数字は、現在のプロセスが年間にかかるコストです。 ``` 年間手動コスト = (インスタンスあたり時間 × 時給 × 年間頻度) + 年間エラーコスト ``` **インスタンスあたり時間**は誰かが実際に費やす時計時間です——待機時間を含む開始から終了までのカレンダー時間ではありません。 **時給**は作業を行う人の全コストです。自分の時間の場合は、ゼロではなく、目標コンサルティングまたは機会コストレートを使用してください。 **年間頻度**はこのタスクが実際に実行される回数です。 **エラーコスト**はほとんどの人が忘れる要素です。 Pickelandの実例:FacebookイベントプロモーションをΩ手動送信するのに週45分かかっていました。機会コストレートで、これは週45ドルまたは年2,340ドルです。これがベースラインです。 ## ステップ2:構築コストの正直な見積もり 構築コストはほとんど常に過小評価されています。 ``` 構築コスト = (開発時間 × 時給) + ツール設定コスト + テストと反復時間 × 時給 + 統合デバッグ時間 × 時給 ``` Picklandイベントプロモーターの場合:構築6時間、テストと調整3時間、統合デバッグ2時間と見積もりました。私のレートで、これは構築コスト990ドルです。 ## ステップ3:運用コストの予測 ``` 年間運用コスト = (年間APIコール数 × コールあたりコスト) + 年間インフラコスト + 人間レビュー時間 × 時給 ``` **APIコール**はClaude/LLMコール、さらにサードパーティAPIです。実際のトークン数に基づいて計算してください。 **インフラ**はCloudflare Workers + Queuesで、中程度のボリュームで月5ドル未満が多いです。 **人間レビュー**は人々が最もよく忘れるコストです。 Pickelandプロモーターの場合:年間約1,000回のClaude APIコール。人間レビューは年約800ドル。合計運用コスト:約810ドル/年。 ## ステップ4:メンテナンス税の適用 これはすべてのエージェントROI計算で最も過小評価されている要素です。エージェントは壊れます。 構築コストの20%を年間メンテナンス税として適用します。 ``` 年間メンテナンスコスト = 構築コスト × メンテナンス率 ``` Pickelandプロモーターの場合:990ドル × 20% = 198ドル/年。 ## 回収公式 ``` 年間純節約 = 年間手動コスト − 年間運用コスト − 年間メンテナンスコスト 回収月数 = (構築コスト ÷ 年間純節約) × 12 ``` Pickelandイベントプロモーターの場合: - 手動コスト:2,340ドル/年 - 運用コスト:810ドル/年 - メンテナンス:198ドル/年 - 年間純節約:1,332ドル/年 - 構築コスト:990ドル - **回収期間:8.9ヶ月** これは境界線です。非戦略的自動化の閾値は6ヶ月です。 ## 私の回収期間閾値 - **3ヶ月未満:** 直ちに構築。これは稀です。 - **3〜6ヶ月:** 明確なイエス。複利効果がある自動化です。 - **6〜12ヶ月:** 戦略的に重要なら構築。そうでなければ中止。 - **12ヶ月超:** ほぼ常に中止。 ## 自動化すべきでない時 チームが犯す最もコストのかかる間違いは、不安定なプロセスを自動化することです。ワークフローが数週間ごとに変わる場合、自動化は現在の欠陥バージョンを固定してしまいます。 自動化前に確認してください:このプロセスは少なくとも3ヶ月安定していましたか? 2番目の間違いは、頻度が低くリスクの高いタスクを自動化することです。3番目:会話を避けるために自動化しないでください。 ## これらの自動化を実行するエージェントスタック 本番で実行するほとんどの自動化は、[Claude](/recommends/claude)をLLMとして使用したCloudflare Workers + Queuesです。インフラコストは本当に低いです。 ## よくある質問 ### 自分の時間にはどの時給を使うべきですか? 機会コスト——その時間を他のことに費やした場合に稼いだり作り出せるものを使用してください。ゼロは使用しないでください。 ### 何も構築する前にClaude APIコストをどう見積もりますか? 実際の入力の代表的なサンプルとターゲットモデルを使用して、Claudeのトークンカウントエンドポイントを使用してください。 ### 「戦略的」自動化とは何ですか? 戦略的自動化は(1)リテンションや転換率に影響する方法で顧客に直接サービスする、(2)手動では達成できない運用規模を可能にする、または(3)より良い意思決定を導くデータを生成します。 ### エージェントの監視に費やす時間を計算すべきですか? はい。監視時間は実際の継続的なコストです。 ### やりたくないと思っているタスクが自動化候補ならどうすればいいですか? タスクを嫌うことには実際のコストがあります。本当に嫌いなタスクに対してより長い回収期間を受け入れますが、それは白紙委任状ではありません。 --- ## 創業者主導の営業:チームを拡大する前に、適切な買い手を見つけて接触する方法 Source: https://alejandrorioja.com/ja/founder-led-sales-how-to-reach-decision-makers/ Published: 2026-07-09 Tags: Entrepreneurship, Growth, Marketing TL;DR: 営業チームを雇う前に、自分で売れることを証明しなければならない。創業者主導の営業は突き詰めると3つに集約される。実際にイエスと言える唯一の人物を特定すること、返信を得るのに十分なリサーチをすること、そしてチャネルを組み立てること — 依頼はメール、時間が勝負のフォローアップは電話、温かい紹介はLinkedIn。多くの商談が止まるのは提案が弱かったからではなく、間違った受信箱に届いたからだ。そこを迂回すれば、有給の営業担当では取れないミーティングを取れる。 ## 目次 _2026年7月公開。_ **TL;DR:** 営業チームを雇う前に、自分で売れることを証明しなければならない。創業者主導の営業は突き詰めると3つに集約される。実際にイエスと言える唯一の人物を特定すること、返信を得るのに十分なリサーチをすること、そしてチャネルを組み立てること — 依頼はメール、時間が勝負のフォローアップは電話、温かい紹介はLinkedIn。多くの商談が止まるのは提案が弱かったからではなく、間違った受信箱に届いたからだ。そこを迂回すれば、有給の営業担当では取れないミーティングを取れる。 **[運営者としての読み解き]** 私が本物の会社を築くのを見てきた創業者は、みな最初の商談を自分の手で売っていた — たいてい最初は下手に、やがて上手に。そこを飛ばす近道はない。自分で一度も回したことのない営業の型は引き継げない。買い手が実際に何に反応するのかを、まだ知らないからだ。これは私自身が使い、創業者に指導しているプロセスだ。適切な相手をどう見つけ、返信を得るのにちょうど十分なリサーチをどう行い、見知らぬ相手に無差別に撒いたりスクレイピングツールを買ったりせずにどう接触するか、を扱う。 ## なぜ創業者がまず売らなければならないのか 自分で一度も回したことのない型は委譲できない。自分でいくつかの商談を成約する前に営業担当を雇えば、それはプロセスを拡大しているのではない — プロセスの発見を外注しているだけであり、本来なら無料で学べたはずのことを学ぶために給料を払っている。 創業者主導の営業は、営業担当を雇える余裕ができるまで我慢する一段階ではない。買い手が使うまさにその言葉、10件のうち9件を潰す反論、そして相手が身を乗り出す一言を学ぶための方法だ。その知識が、後になってスクリプトになり、プレイブックになり、採用の基準になる。これを飛ばせば、最初の営業採用者は当て推量を引き継ぐことになる。 良い知らせもある。創業者として、あなたは営業担当が決して持てない不公平な優位を持っている。あなたはそのものを作った。どんな質問にも答えられ、電話中にロードマップを曲げられ、ノルマを背負った見知らぬ相手には偽装できない信頼性を持って語れる。あなたの仕事は、その優位が意味を持つほど頻繁に、適切な相手の前に立つことだ。 ## ステップ1:イエスと言える唯一の人物を特定する アウトリーチが失敗する最もよくある理由は、間違った役職に届くことだ。あなたのメッセージは拒否されるのではない — それに基づいて動く権限を一度も与えられていない誰かに受け取られ、静かに死んでいく。 ほとんどの企業では、あなたと商談の間に3種類の人物が座っている。 - **チャンピオン** — あなたの製品が解決する痛みを感じており、それを直したいと思っている。役職は高くないことが多いが、社内であなたの主張を担いでくれる人物だ。 - **経済的意思決定者** — 予算を握り、支出を承認できる。最終的にイエスと言うのはこの人だ。 - **ブロッカー/ゲートキーパー** — 購買部門、秘書、IT、あるいはノイズを濾過するのが仕事の懐疑的な側近。敵ではないが、狙う相手でもない。 誰かに連絡する前に、自分が誰を狙っているのか、そしてなぜかを決めよう。最初のミーティングでは、通常チャンピオンか経済的意思決定者を狙いたい — 見つけやすかったという理由だけで名前を拾った適当な社員では、決してない。間違った相手に届くのは、そのメッセージを無駄にするだけではない。あなたの名前が狙いを外したコールドピッチに紐づくことになり、そのアカウントごと焼き払いかねない。 なぜその特定の人物が適切なコンタクトなのかを言葉にできないなら、あなたはまだ連絡する準備ができていない。 ## ステップ2:返信を得るのに十分なリサーチをする コンタクトのリサーチとは「メールアドレスを見つける」ことではない。あなたのメッセージが、その一人のためにしか書かれ得なかったと言えるだけの文脈を組み立てることだ。それが、週に50件のピッチが届く受信箱で返信を得るものだ。 何かを書き始める前に、次のことを把握しておこう。 1. **きっかけ** — なぜ今なのか? 資金調達、関連する役割での新規採用、製品ローンチ、公になった苦情、ギャップをあらわにする求人。そのタイミングが*相手にとって*理にかなう理由だ。 2. **具体的な痛み** — 「あなたのような会社はXに苦労する」ではなく、*この*会社が苦労しているという証拠だ。 3. **つながる糸** — 共通の知人、その領域にいる顧客、テンプレートでは偽装できないあなたが気づいた何か。 公開情報だけで、特別なツールなしにこのほとんどが手に入る。会社自身のサイトと採用ページ、LinkedIn、直近の報道、ポッドキャスト出演、上場企業なら決算説明会、そして買い手が実際にたむろするコミュニティだ。市場をきちんと検証していれば、この作業の一部はすでに済んでいる — 営業インテリジェンスも兼ねる需要と競合のリサーチについては[構築する前にビジネスアイデアを検証する方法](/how-to-validate-a-business-idea/)を参照してほしい。 十分なリサーチができたかを確かめるテストはこうだ。メッセージの最初の2文を、他のどの会社に送っても*まったく意味をなさない*ように書けるか? もし書けるなら、準備はできている。冒頭が100社に通用してしまうなら、リサーチを続けよう。 ## ステップ3:チャネルを組み立てる — メール、電話、LinkedIn 唯一最良のチャネルなど存在しない。あるのは、それぞれの瞬間にとって最良のチャネルだ。間違いは1つを選んで叩き続けることだ。技術は、各チャネルが実際に得意な仕事をするように組み立てることにある。 | チャネル | 最適な用途 | 下手に使ったときのリスク | | --- | --- | --- | | メール | 主要な依頼、詳細なフォローアップ、買い手が社内転送する必要のあるあらゆるもの | テンプレートに見えれば即座に無視される | | 電話 | 時間が勝負のフォローアップ、予約済みだが流れかけている商談の日程調整、かけるよう言われた温かい紹介 | 事前の文脈や理由がないと押しつけがましく感じられる | | LinkedIn | 柔らかな初回接触、コールドな相手を温める、メールの合間に存在感を保つ | 混み合い、遅く、他のあらゆるピッチと同じに見えやすい | | 温かい紹介 | 得られるなら、あらゆる場面 | 紹介者の信頼がかかっている — 無駄にしてはいけない | 実際に機能するシーケンスはこうだ。見つけたきっかけに結びつけた、短く具体的なメールで口火を切る。返信がなければ、LinkedInで価値を加える — 真摯なコメント、有用なリソース、文脈を添えたつながり申請 — こうしてあなたの名前がコールドな不意打ちにならないようにする。電話へのエスカレーションは、本当の理由があるときだけにする。締め切り、紹介、関心の後に静かになった商談などだ。あなたの名前を一度も聞いたことのない相手への、どこからともない電話は、スパムに分類される最速の方法だ。 そして、得られるなら常に温かい紹介を優先しよう。買い手が信頼する誰かからのたった1つの紹介は、完璧に練り上げた20通のコールドメールを上回る。コールドに動く前に、自分のネットワークの誰がどの扉を開けられるかを把握することに、本気で労力を注ごう。 ## ステップ4:返事がもらえるメッセージを書く 連絡する資格を得たら、メッセージは短く保ち、イエスと言いやすくしよう。見知らぬ相手からの長いピッチは読まれない。アーカイブ行きだ。 良いコールドメールは、90語未満で4つのことをする。 1. **きっかけを名指しする** — 注意を払っていること、これが一斉送信ではないことを証明する。 2. **関連する痛みを述べる** — 1文で、自分の話ではなく相手の話として組み立てる。 3. **小さな依頼を1つする** — 「パートナーシップを模索しましょう」ではなく、15分の通話を。 4. **簡単な逃げ道を与える** — 「もしあなたの担当でなければ、担当の方を教えていただけますか?」 その形はこうだ。 > 「Priyaさん、こんにちは。RevOpsチームで求人を2件出したばかりだと拝見しました。これはたいてい、増員が追いつくより速くレポーティングが辛くなっているサインです。私たちはシリーズBのチームが、スタックを剥がすことなく手作業のレポーティング時間を約60%削減するお手伝いをしています。関連しそうか確かめるため、来週15分いかがでしょうか? そしてもしこれがあなたの領域でなければ、担当の方を教えていただけると助かります。」 これは具体的で、相手の時間を尊重しており、答えるのがきわめて簡単だ — 「ノー」でさえ有用だ。それが適切な相手へとあなたを導いてくれるからだ。同じ規律はチャネルを越えて適用される。フラグを立てられたり無視されたりせずにアウトリーチを規模化する、より深い仕組みが知りたければ、[成功するアウトリーチ戦略の作り方](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/)で詳しく分解した。 ## ステップ5:そのミーティングが得られる唯一の機会であるかのように準備する アクセスは糸口を与えてくれる。次の一歩を得るのは準備だ。創業者は、ミーティングを取るために何週間も戦い、買い手の世界を考え抜かないまま部屋に入り込む — そして商談は関心の欠如ではなく、備えの欠如で死んでいく。 どんな通話の前にも、即答できるようにしておこう。 - この人物の一日はどんなもので、私の製品はその中のどこにはまるのか? - この人が気にしている、私が動かせる唯一の成果は何か? - この人が持ち出す2つの反論は何で、私の正直な答えは何か? - 相手が関心はあるがまだ踏み切れないとき、私が求められる最小の次の一歩は何か? あなたが製品を作ったのだから、デモは簡単だ。難しいのは、自分の優先事項ではなく買い手の優先事項を頭の中に保つことだ。アウトリーチを収益に変える創業者は、すでにそのビジネスを理解しているかのように聞こえる形で現れる — ステップ2で仕事をしたからだ。 ## 連絡すべきでないとき 攻撃的なアウトリーチは、築くよりも多くのパイプラインを焼き払う。次のときは、コールドな接触を飛ばす — あるいは速度を落とそう。 - なぜこの特定の人物が適切なコンタクトなのかを言葉にできないとき。 - すでに返信なしで2回を超えてフォローアップしたとき。(次に進もう。市場は広い。) - 冒頭が、他の100社に送っても通用してしまうとき。 - 通常の営業時間外に、あるいは事前の文脈なしに電話しようとしているとき。 - その人を選んだ唯一の理由が、連絡先が見つけやすかったことであるとき。 良いアウトリーチは、下調べをした誰かからの、タイミングの良い関連性のあるメモのように感じられる。悪いアウトリーチは、ターゲティングが少しマシなだけのスパムのように感じられる。その違いは、まるごとリサーチと自制の中にある。 ## 創業者主導の営業スタック 私がこのために頼っているツールと習慣。どれも営業チームを必要としない。 - **リサーチ:** 会社自身のサイトと採用ページ、LinkedIn、直近の報道、そして買い手が実際に話しているコミュニティ - **CRM:** 実際に自分が更新するもの — 無視するエンタープライズCRMより、シンプルなNotionボードやAirtableが勝る - **シーケンシング:** 誰がどの段階にいて次の接触は何かを追う軽量なトラッカー。こうして何も流れ去らないようにする - **メール:** 本物の、温めた送信アドレスとプレーンテキストのメッセージ — 画像なし、トラッキングピクセルなし、「キャンペーン」だと叫ぶものは一切なし - **カレンダー:** 「イエス」が5往復の返信メールではなく1クリックでミーティングになる予約リンク ## 運営者としての結論 売り始めるのに営業チームは要らない。要るのは、誰がイエスと言えるのかを正確に知ること、あなたのメッセージがその人のためにしか書かれ得なかったと言えるだけのリサーチをすること、そして各チャネルがそれぞれの仕事をするように組み立てることだ。メールが依頼を運び、LinkedInが地ならしをし、電話が時間の勝負の隙間を埋め、温かい紹介がそのすべてを上回る。何が実際に刺さるのかを学べるだけの回数、自分でこなそう — そのとき、そのときになって初めて、苦労して手に入れたプレイブックを最初の採用者に引き渡すのだ。 --- **関連:** [成功するアウトリーチ戦略の作り方](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) · [ビジネスアイデアを検証する方法](/how-to-validate-a-business-idea/) · [グロースマーケティング戦略ガイド](/growth-marketing-strategies-guide/) --- ## ソロプレナービジネスの作り方:2026年完全ガイド Source: https://alejandrorioja.com/ja/how-to-build-a-solopreneur-business/ Published: 2026-07-07 Tags: Entrepreneurship, Growth TL;DR: ビジネスモデルを1つ選び(コンテンツ、サービス、SaaS、またはデジタル製品)、特定のニッチを中心にオーディエンスを構築し、主要モデルが収益を上げ始めたら二次的な収益源を加えましょう。罠は4つすべてを同時に始めることです——最も受動的に見えるものではなく、すでに知っていることに合ったモデルを選んでください。 ## 目次 _2026年7月更新。_ **TL;DR:** ビジネスモデルを1つ選び(コンテンツ、サービス、SaaS、またはデジタル製品)、特定のニッチを中心にオーディエンスを構築し、主要モデルが収益を上げ始めたら二次的な収益源を加えましょう。罠は4つすべてを同時に始めることです——最も受動的に見えるものではなく、すでに知っていることに合ったモデルを選んでください。 **[オペレーターの視点]** 私はこのサイトを運営し、コースを販売し、フルタイム従業員なしで何年もアフィリエイト収益を管理してきました。どれも大きな計画から始まったわけではありません——1つうまくいったことから始まり、そこから意図的に拡大しました。このガイドは、すべてを一度にやろうとする前に読んでおけばよかったと思うものです。 ## ソロプレナービジネスとは本当に何か ソロプレナーは一人でビジネスを運営します——共同創業者も従業員もなく、量が必要な時だけ請負業者を使うかもしれません。目標は、人数ではなく専門知識とシステムで動くビジネスです。 これはフリーランスとは異なります。フリーランサーは時間を売ります。ソロプレナーは、稼いだ1円ごとに自分の時間を必要とせずに収益を生み出すシステムを構築します。 ## ソロプレナーの4つのビジネスモデル すべての一人ビジネスは、おおよそこのどれかに当てはまります: 1. **コンテンツビジネス。** ブログ、ニュースレター、YouTube、ポッドキャストなどで発信し、広告、アフィリエイト収益、スポンサー、自社製品で収益化します。参入障壁が最も低く、立ち上がりが最も遅い。 2. **サービスビジネス。** クライアントに特定の成果を提供します——コンサルティング、フラクショナルな役割、done-for-youサービス。月10万円への最速ルートだが、最もスケールしにくい。 3. **デジタル製品。** コース、テンプレート、電子書籍、ツール。一度作れば高レバレッジだが、既存のオーディエンスなしにトラフィックを集めるのは難しい。 4. **マイクロSaaS。** 特定の問題を解決する小さなソフトウェア製品。上限が最も高く、技術的なハードルも最も高い。 正しいモデルは、すでに何を持っているか——スキル、オーディエンス、または資本——によって決まります。 ## ステップ1:真の深さのあるニッチを選ぶ 広いニッチ(マーケティング、金融、健康)にはトラフィックがありますが、競争が熾烈です。狭いニッチ(ECファウンダー向けAIツール、新人看護師向け個人財務)は、コンバージョンが良くランクも上がりやすい。 私が使うテスト:このトピックについてアイデアが尽きることなく50本の本当に役立つコンテンツを書けるか?もしそうなら、ニッチには深さがあります。20本も思いつかないなら、狭すぎるか、十分に知らないかのどちらかです。 あなたのニッチはこれらの交差点にあるべきです: - 調査だけでなく、経験から知っていること - お金や時間を使う余裕のあるオーディエンス - 一度きりの解決策ではなく、繰り返し起きる問題 ## ステップ2:必要になる前にオーディエンスを構築する 私がよく見る最大のミス:ゼロのオーディエンスに製品を発売すること。 オーディエンスが先、製品が後というのがルールです。実際に機能することはこれです: 1. **1つのディストリビューションチャネルを選んで深く掘り下げる。** ブログ+SEOは遅いが耐久性があります。ニュースレターは収益化が早い。短形式動画は上限が高いがアルゴリズム依存。1年目は4つのプラットフォームに注意を分散させないでください。 2. **売るものがない間も一貫して発信する。** 売るものがない時に構築したオーディエンスは、ついに売り始めた時にあなたを信頼します。 3. **初日からメールリストを構築する。** ソーシャルフォロワーは借り地です。メールリストはあなたのものです。私は[ConvertKit](/recommends/convertkit)を使っています——シーケンスとブロードキャストを邪魔なく処理してくれます。 役立つベンチマーク:1,000人の真のファン(毎回メールを開く購読者)でデジタル製品から年間1,000万円以上を生み出すのに十分です。 ## ステップ3:まず主要な収益源を最適化する オーディエンス(またはサービスのクライアント)ができたら、二次的なものを追加する前に主要な収益源に集中してください。 **コンテンツビジネスの場合:** アフィリエイト収益が最初の収入として最速です。使っているツールについて書き、おすすめページを通じてリンクし、パーセンテージを稼ぎます。製品を作る必要も、カスタマーサポートも不要。上限は現実的で——儲かるニッチの高トラフィックサイトは月500万〜3,000万円稼ぐこともあります——でもこれは私が見つけた最良のブートストラップの仕組みです。 **サービスビジネスの場合:** 快適に感じるより多く請求してください。値下げがソロプレナーの最も一般的なミスです。クローズ率が100%なら、安すぎます。 **デジタル製品の場合:** スコープを狭く保ってください。焦点を絞った97ドルのコースは、コンバージョン率と完了率で497ドルの広範なコースを上回ります。 **マイクロSaaSの場合:** 自分が個人的に抱えている痛みのために構築してください。自分自身がターゲット顧客である場合、共感の優位性は本物です。 ## ステップ4:二次的な収益源を積み上げる 主要なモデルがコンバートし始めたら、比例した時間を必要としない収益源を加えてください: - **アフィリエイト収益** ——サービスビジネスやSaaSオペレーターも、コンテンツからアフィリエイト収益を得ることができます - **デジタル製品** ——主にサービスビジネスであっても、コースやテンプレートセットは眠っている間に収益を上げることができます - **スポンサーシップ** ——オーディエンスが約5,000人のエンゲージされた購読者を超えたら - **ライセンス** ——システムやツールを構築した場合、隣接するニッチの他者にライセンスを与える 積み上げは戦略ではなく結果です。まず1つの流れを機能させてください。 ## ソロプレナーのテックスタック 私はこの全オペレーションを6つのツールで運営しています: | ツール | 機能 | |---|---| | [Claude](/recommends/claude) | コンテンツ、メール、コードの初稿作成 | | [ConvertKit](/recommends/convertkit) | メールリスト、自動化、配信 | | [Notion](/recommends/notion) | 編集カレンダー、クライアント文書、SOP | | [Canva](/recommends/canva) | ソーシャルグラフィックとサムネイルデザイン | | [Airtable](/recommends/airtable) | アフィリエイトトラッキング、CRM、コンテンツデータベース | | [SEMrush](/recommends/semrush) | キーワードリサーチと順位追跡 | 月間合計コスト:300ドル未満。このスタックを置き換えるチームは、給与だけで月15,000ドル以上かかるでしょう。 ## ソロプレナービジネスを殺す3つのミス 1. **早まったスケーリング。** ビジネスモデルが証明される前に採用すると、繰り返し収益が生まれる前にリソースを消耗し、管理オーバーヘッドが加わります。 2. **早すぎる多様化。** 4つの半機能する収益源は、完全に最適化された1つより少ない収益しか生みません。1年目は広げるのではなく深く掘り下げてください。 3. **ディストリビューションなしで構築する。** オーディエンスのない最高の製品は、大きなエンゲージされたリストを持つ平凡な製品には勝てません。ディストリビューションが堀です。 ## オペレーターの結論 ソロプレナービジネスは、チームの複雑さを所有権とマージンと交換する意図的な選択です。私が一貫して機能するのを見てきたビジネスは皆、同じパターンを共有しています:1つのモデル、1つのニッチ、1つのディストリビューションチャネル、複利成長するのに十分な期間続けること。 既存のスキルに合ったモデルを選んでください。必要になる前にオーディエンスを構築してください。主要なものがコンバートした後だけ収益源を追加してください。残りは実行です。 --- **関連記事:** [ビジネスアイデアの検証方法](/how-to-validate-a-business-idea/) · [ニュースレターを収益化する方法](/how-to-monetize-a-newsletter/) · [個人ブランドの構築方法](/how-to-build-a-personal-brand/) --- ## AIエージェントで中小企業を自動化する方法:実践ガイド Source: https://alejandrorioja.com/ja/how-to-automate-your-small-business-with-ai-agents/ Published: 2026-07-04 Tags: AI Agents, Entrepreneurship, Operations TL;DR: AIエージェントで中小企業を自動化することは、人を置き換えることではありません。繰り返しのルールベースの作業を委任して、あなたにしかできない意思決定に時間を使えるようにすることです。1つのタスクから始め、すべてを記録し、お金や顧客に直接関わることには人間をループに保ち、そこから拡張します。2つのビジネスで使用するスタックは月額合計100ドル未満です。 ## 目次 _2026年7月更新。_ **TL;DR:** AIエージェントで中小企業を自動化することは、人を置き換えることではありません。繰り返しのルールベースの作業を委任して、あなたにしかできない意思決定に時間を使えるようにすることです。1つのタスクから始め、すべてを記録し、お金や顧客に直接関わることには人間をループに保ち、そこから拡張します。2つのビジネスで使用するスタックは月額合計100ドル未満です。 **オペレーターからの一言:** 私はテキサス州プフルーガービルに9コートの屋内ピックルボール施設(Pickleland)とコンサルティングブランドの2つのビジネスを経営しています。合わせると、ソーシャルメディアのコメント返信からイベントプロモーション、ニュースレターの下書き、予約フォローアップまで、30以上のAIエージェントが本番環境で稼働しています。これは、実際に機能すること、時間を無駄にすること、そして開発者を雇わずに始める方法についての率直なガイドです。 正直な前置き:中小企業向けのAIエージェントは魔法ではありません。顧客関係、製品品質、戦略的判断力という困難な仕事を置き換えるものではありません。彼らがすることは、すべてのオペレーターが毎日2〜3時間費やす管理上の雑用——受信トレイの整理、コピー&ペーストのレポート、ソーシャルへの返信、データのフォーマット——を排除することです。それだけで違いをもたらすには十分です。 ## 自動化がうまくいく4種類の作業 何かを構築する前に、作業負荷を4つのカテゴリに分類してください。そのうちAIエージェントに適しているのは1つだけです。 ### 1. ルールベース、繰り返し、テキスト入力/テキスト出力 これが最適なポイントです。顧客メールの分類、ソーシャルメディアのコメントへの返信の下書き、1週間の予約を箇条書きにまとめる、CSVをレポートに再フォーマットする。入力はテキスト、出力はテキスト、ルールは一貫している。これらのタスクは、1回のプロンプトとAPIの薄いラッパーで自動化されます。 **Picklelandの例:** - コートに関する問い合わせメールの分類(質問/苦情/予約/その他) - 今後のイベントに関するFacebookグループの投稿の下書き - 予約システムからの週次稼働率サマリーの生成 ### 2. 明確な引き継ぎを持つ複数ステップのパイプライン 3つのステップを持つタスク——データを取得し、変換し、通知を送信する——各ステップに明確な入力と出力があるもの。これは軽量なオーケストレーションレイヤーと組み合わせると効果的です(私はCloudflare Workers Queuesを使用しています)。重要なのは、各ステップが独立して失敗でき、作業全体をやり直すことなく再試行できることです。 **Picklelandの例:** - 新規予約 → CRM更新 → 確認メール → Slack通知 - フォーム送信 → 分類 → 宛先指定の返信下書き → 人間のレビューキュー ### 3. モニタリングとアラート 条件を監視し、それが発生したときに通知するエージェント。これらはダッシュボードを手動でチェックする認知的負荷を置き換えるため、投資対効果が最も高いAI自動化の1つです。また、最もシンプルなものの1つでもあります:ロジックは単純に「Xが閾値を超えているか?はいなら、アラートを送る」だけです。 **私のコンサルティングブランドの例:** - Google Analytics異常アラート(トラフィックの低下、急増) - 予約キャンセル率が週次基準を上回る - 新しいレビューが投稿された——人間の返信のためにフラグを立てる ### 4. コンテンツの初稿(最終製品ではない) AIエージェントは、ソーシャル投稿、メールニュースレター、ブログのアウトライン、製品説明を役立つ品質で下書きできます。ただし、あなたの編集上の判断を置き換えることはできません。すべての下書きは人間のレビューステップを経ます。ROIは、空白の画面ではなく70%の完成度から始められることから生まれます。 **自動化がうまくいかないもの:** 顧客関係管理、価格設定の決定、営業会話、採用、そして間違った出力が実際の人に実際のコストをもたらすもの。これらには人間を維持してください。 ## 実際に使用しているスタック これにエンタープライズソフトウェアは必要ありません。私の自動化を動かしているものです: 1. **[Claude](/recommends/claude)** — すべてのAIタスクのモデルレイヤー。GUIではなく直接APIを使用しています。ドル当たりの品質はテストした中で最高で、[プロンプトキャッシング](/prompt-caching-cut-your-claude-costs-without-switching-models/)はシステムプロンプトが繰り返される際にコストをさらに削減します。 2. **Cloudflare Workers** — エージェントが住む場所。サーバーレス、グローバル分散型で、無料ティアがほとんどの中小企業のワークロードをカバーします。`scheduled`ハンドラーはcronタスクを実行し、`fetch`ハンドラーはイベントトリガーフローのwebhookを受信します。 3. **Airtable** — データのバックボーン。すべてのエージェントがAirtableテーブルから読み取り、書き込みます。ジョブのステータス、レビューキュー、運用データがここに存在します。開発者でない人もコードに触れることなくデータを編集できます。 4. **Kit(旧ConvertKit)** — メールとニュースレターの自動化。私のニュースレター下書きエージェントがKitの下書きに書き込み、私がレビューして送信します。 2つのビジネスで30以上のエージェントの月額総コスト:100ドル未満。最大の費目はClaude APIの使用料です。その他はすべて無料ティアまたはほぼ無料です。 ## 実際の例:Picklelandの自動化 ### イベントプロモーター 毎週日曜日、スケジュールされたエージェントが予約システムをチェックして今後4日間のイベントを確認します。各イベントを関連するローカルFacebookグループにマッチングし、各グループに適したプロモーション投稿を下書きします。下書きはAirtableのレビューテーブルに入ります。私は5分でレビューして「承認」をクリックします——エージェントが40分の下書き作業を担います。私の承認なしに自動的に投稿されるものは何もありません。 これは[スケジュールされたエージェントパターン](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/)です——スケジュールで実行し、バッチ作業を行い、人間のレビューのために下書きを提示します。 ### ソーシャルコメント分類器 監視されているFacebook投稿に新しいコメントが来ると、webhookが発動し、エージェントが意図を分類します:質問、苦情、称賛、またはスパム。信頼度の閾値を超えた質問と苦情については、返信を下書きしてレビューのためにフラグを立てます。称賛はログに記録されます。スパムは抑制されます。コメントから下書きまで30秒のサイクル。エージェントなしでは各コメントが手動のコンテキスト切り替えでした;今では事前に下書きされた返信のキューは30分ではなく5分で処理できます。 これは[イベントトリガーエージェントパターン](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/)です——webhookで起動され、素早く応答する必要があります。 ### 週次運用ブリーフ 毎週月曜日の朝、エージェントが前週の予約データ、キャンセル率、コートタイプ別の稼働率、フラグの立てられた異常を取得します。5点のサマリーをフォーマットしてNotionページに格納します。コーヒーを飲みながらそれを読み、20分ではなく2分で週に必要な運用上のコンテキストを把握できます。 ## どこから始めるか:4つのステップ ### ステップ1:毎週行う最も摩擦の多い繰り返しタスクを選ぶ 最も華やかなものや最も戦略的なものではなく——最も苦になっているもの。3つのソースからコピー&ペーストしている週次レポート。1時間費やすソーシャルへの返信。1通ずつ送るフォローアップメール。それがあなたの最初のエージェントです。 ### ステップ2:タスクを入力と出力にマッピングする 以下を書き出してください: - タスクを起動するもの(時計、イベント、フォーム送信) - 必要な入力(データソース、テキスト、コンテキスト) - 出力は何か(下書き、通知、データベース行) - 人間のレビューステップは何か(すべての最初のエージェントはこれを持つべき) 明確にマッピングできない場合、タスクは自動化するには十分に定義されていません。まず手動でプロセスを明確にしてください。 ### ステップ3:可能な限り小さなバージョンを構築する システムではなく。1つのプロンプト、1つのAPI呼び出し、1つの出力。入力を受け取り、Claudeを呼び出し、下書きを返すTypeScript関数。データベースなし、webhookなし、キューなし——コアロジックのみ。手動で5回実行してください。出力の品質は維持されますか?はいなら、動作するエージェントができています。その後インフラを追加します。 ```typescript // 最もシンプルな最初のエージェント:イベントプロモ下書き async function draftEventPromo(event: PadklelandEvent, env: Env): Promise { const msg = await env.ANTHROPIC.messages.create({ model: "claude-opus-4-8", max_tokens: 400, system: `You write Facebook event promo posts for Pickleland, an indoor pickleball facility in Pflugerville, TX. Tone: friendly, local, community-focused. Max 150 words.`, messages: [ { role: "user", content: `Write a promo post for this event: ${JSON.stringify(event)}`, }, ], }); return (msg.content[0] as { text: string }).text; } ``` ### ステップ4:機能を追加する前に可観測性を追加する すべての実行をトレースIDで記録してください。入力、出力、タイムスタンプを記録してください。洗練されたツールは必要ありません——stdoutへの構造化JSONで始めるには十分です。理由:最初のエージェントは予測しなかった方法で失敗します。それが起こったとき、状態を記憶から再構築せずに何が起こったかを確認できる必要があります。 これは、エージェントスタックをスケールするオペレーターと、1つの悪い経験の後に諦めるオペレーターを分ける習慣です。[本番でAIエージェントをデバッグする方法](/how-to-debug-an-ai-agent-in-production/)でこれを詳しく説明しています。 ## よくあるミス(と回避方法) **プロセスを理解する前に自動化する。** 自分でタスクを一貫して実行できない場合、AIエージェントはスケールで一貫性なく実行するだけです。まず手動でプロセスを文書化し、それから自動化してください。 **人間のレビューステップを早まって削除する。** 各エージェントをヒューマン・イン・ザ・ループのレビューで始めてください。2週間実行させ、すべての出力を確認し、完全に自動化する前に信頼を構築してください。例外は低リスクで簡単に元に戻せるアクション(フォルダへの下書きの書き込みなど)です。 **コアを検証する前にシステム全体を構築する。** まず最もシンプルなバージョンを構築してください。1つのプロンプトでコアの品質が得られない場合、より多くのインフラでは解決できません。 **コストを無視する。** AI APIのコストは使用量に応じて増加します。大量にデプロイする前に実行コストを把握してください。週に何千回も実行する場合、[HaikuとSonnetのコスト計算](/ai-agent-cost-math-when-haiku-beats-sonnet/)は重要です。 **失敗を大惨事として扱う。** エージェントは失敗します。プロンプトは退行します。APIはダウンします。リトライロジックを構築し、[評価ハーネス](/the-eval-harness-i-use-to-ship-ai-agents/)を構築し、失敗をデータとして、大惨事としてではなく扱ってください。 ## すべてを変えるマインドセットの転換 中小企業のボトルネックはほとんどの場合お金ではありません——オーナーの時間と注意力です。エージェントが処理できるタスクに費やすすべての時間は、顧客、製品、戦略に費やさなかった時間です。 私が使用するフレーム:タスクを明確な入力と出力を持つ繰り返し可能なプロセスとして書き出せるなら、それはエージェントの候補です。判断、関係性、創造性が必要なものはすべて私のもとに残ります。エージェントが前者を処理することで、私は後者に集中できます。 AIエージェントを始めるのに、技術的な共同創業者も、6桁のソフトウェア予算も、数ヶ月の構築期間も必要ありません。高摩擦のタスクを1つ選び、機能する最小バージョンを構築し、出力から学ぶことが必要です。ほとんどのオペレーターは週末に最初の動作するエージェントを見つけます。そこから、2番目は午後1つかかるだけです。 ## FAQ ### 中小企業でAIエージェントを実行するにはいくらかかりますか? 私のスタックは月100ドル未満で30以上のエージェントを実行しています。最大のコストはAI APIの使用(Claude)です。Cloudflare Workersは1日100,000リクエストまで無料で、以降は月5ドルです。Airtableは中小企業のほとんどのデータニーズをカバーする無料ティアがあります。コストは使用量に応じて増加します——週に数回実行する単一のエージェントは無視できるほどです。 ### AIエージェントを構築するに開発者が必要ですか? 基本パターン——スケジュールされたcron、webhookハンドラー、シンプルなプロンプト——は、少しのJavaScriptとドキュメントを読む意欲があれば対応できます。より複雑なパイプライン、オーケストレーション、本番グレードの可観測性には、開発者が作業を速めます。私のコース([AIエージェント入門](/ai-agents-for-beginners-cowork-codex-guide/))はオペレーターのためのノーコードとローコードのパスを教えています。 ### 中小企業にとって最初のAIエージェントは何が最適ですか? 週次運用ブリーフ。スケジュールで実行され、明確な入力(データソース)があり、一貫した出力(フォーマットされたサマリー)を生成し、下振れリスクはゼロです——下書きが間違っていれば、読まなければいいだけです。顧客や運営にリスクなく、エージェントができることとできないことについての直感を構築します。 ### ビジネス自動化にはどのAIモデルを使用すべきですか? ほぼすべてのエージェント作業にClaudeを使用しています。APIの品質、信頼性、オペレーターに優しい価格設定(特に[プロンプトキャッシング](/prompt-caching-cut-your-claude-costs-without-switching-models/)と組み合わせて)が本番使用に適した選択肢となっています。安価で高ボリュームの分類タスクには、Claude Haiku 4.5が高速かつ安価です。下書きや細かいタスクにはClaude SonnetまたはOpus。 ### AIエージェントがビジネスを傷つけるミスをするのを防ぐにはどうすればいいですか? 3つの実践:顧客やお金に直接関わるすべてのことに人間をループに保つ;何が問題になったかを追跡できるようにすべての実行を記録する;プロンプトへの変更が本番を静かに壊さないよう[評価ハーネス](/the-eval-harness-i-use-to-ship-ai-agents/)を構築する。低リスクの内部タスクから始め、出力品質を信頼してからのみ拡張してください。 --- ## オンラインでパーソナルブランドを構築する方法:2026年実践者プレイブック Source: https://alejandrorioja.com/ja/how-to-build-a-personal-brand/ Published: 2026-07-02 Tags: Entrepreneurship, Growth TL;DR: パーソナルブランドは、特定のターゲット層を選び、一つのチャネルで有益なコンテンツを継続的に発信し、明確な視点を持つことで構築される——LinkedInのプロフィールを最適化することではない。ニッチを絞り、実際の経験から書き、メールリストを唯一の自己所有チャネルとして構築し、適切な人々があなたを見逃せなくなるまで繰り返す。 ## 目次 _2026年7月更新。_ **TL;DR:** パーソナルブランドは、特定のターゲット層を選び、一つのチャネルで有益なコンテンツを継続的に発信し、明確な視点を持つことで構築される——LinkedInのプロフィールを最適化することではない。ニッチを絞り、実際の経験から書き、メールリストを唯一の自己所有チャネルとして構築し、適切な人々があなたを見逃せなくなるまで繰り返す。 **[実践者からのメモ]** 私は複数のビジネス——Pickleland、AIエージェントコンサルティング、このサイト——で公開的に構築してきた。繰り返し見るパターンは常に同じだ:認知されるパーソナルブランドを構築する人たちは最も才能があるわけではない。最も具体的で、最も一貫しているのだ。私が使用し推薦するフレームワークを紹介する。 ## パーソナルブランドとは本当に何か(そして何ではないか) パーソナルブランドは一つの質問への答えだ:*あなたがいない場所で、人々はあなたについて何と言うか?* ロゴではない。カラーパレットではない。フォロワーの数でもない。パーソナルブランドとは、人々があなたの名前を聞いたときに形成するメンタルショートカット——あなたが解決できると思われる特定の問題、あなたに期待する視点だ。 ほとんどの人が犯す間違い:視点を発展させる前にブランドを構築しようとすること。ブランドとは、本物のことをして、そこから学んだことに具体的であることで積み重なるもの——前もって作り上げるものではない。 最初からコントロールできること: 1. 誰に話しかけるか 2. 彼らのためにどんな問題を解決するか 3. 彼らがあなたをどこで見つけるか 4. どれだけ一貫して現れるか 時間とともに積み重なること: - 特定の専門知識に対する評判 - あなたの判断を信頼する読者層 - 追いかけなくても来る受信機会 ## ステップ1:生き続けられる最も狭いニッチを選ぶ パーソナルブランディングで最も一般的な失敗パターンは、広すぎること。「マーケティング専門家」「ビジネスコンサルタント」「テック起業家」——誰もが持っている世界では、これらは意味のないラベルだ。 狭くすればするほど、早く評判が築ける。 このフィルターでニッチをテストせよ: - **検索されるほど具体的か。** 誰かがあなたのニッチをGoogleで検索し、周囲に実際のコミュニティを見つけられるか? - **紹介されるほど具体的か。** 誰かがあなたと全く同じ問題を持つ人と出会ったとき、最初にあなたのことを考えるか? - **2年以上コンテンツを生産できるほど広いか。** [Semrush](/recommends/semrush)のようなキーワードツールを使って、あなたのニッチが検索されているかを確認しよう。 ## ステップ2:一つの主要チャネルを選ぶ 同時に至る所にいようとするのは、至る所で凡庸になる確実な方法だ。最初は一つのチャネルを選び、深く掘り下げよう。 - **書かれたコンテンツ(ブログ/ニュースレター):** 分析的・実践者向け読者層に最適。SEOを通じて時間とともに複利で成長。 - **LinkedIn:** B2Bおよびプロフェッショナル向け読者層に最適。 - **YouTube/動画:** 視覚的なデモンストレーションが効果的なトピックに最適。 - **X/Twitter:** 広まりやすいアイデアに最適。 ## ステップ3:自分の視点を見つける 視点のないコンテンツはノイズだ。引用され、推薦され、求められるパーソナルブランドを区別するのは、独自の視点——実際の経験から得た、世界の仕組みに関する意見だ。 強い視点はこれらの特性を持つ: - 単に読んだだけでなく、実際にやったことに基づいている - 読者の少なくとも一つの慣習的な仮定に挑戦する - 一部の人が同意しないほど具体的だ ## ステップ4:所有する読者層を構築する 構築するすべてのプラットフォームはアルゴリズムを変更したり、アカウントを停止したり、閉鎖したりする可能性がある。本当に所有できる唯一の配信チャネルはメールリストだ。 最初の日からそれを構築し始めよう。メールには[ConvertKit](/recommends/convertkit)を使用している——クリエイターのニュースレター専用に構築されている。 パーソナルブランドからメールリストを最速で成長させる方法: 1. **本当に有用なリードマグネットを作成する。** 読者が直面する特定の問題を解決するチェックリスト、テンプレート、または短いガイド。 2. **各コンテンツページのフォールドより上にオプトインを追加する。** 3. **3通のウェルカムメールシーケンスを書く。** 4. **すべてのコンテンツでリストに言及する。** ## ステップ5:一貫して発信する——複利の数学 毎週一本の長文コンテンツを発信すると: - **1〜8週目:** ほぼ誰も読まない。これは正常だ。 - **3〜4ヶ月目:** 一部のコンテンツがオーガニックトラフィックを得始める。 - **6〜9ヶ月目:** 検索トラフィックが複利で成長。インバウンドの問い合わせが現れ始める。 - **2年目:** 100本のコンテンツ。名前が検索やAIの回答に現れる。 私のルール:機能しているかどうかを評価する前に、6ヶ月コミットする。 ## ビジュアルブランドについての考え方 最小限のビジュアルブランド: - 顔がはっきり見えるプロフェッショナルなプロフィール写真 - すべてのプラットフォームで統一したプロフィール写真 - 明確なタグラインとメール登録フォームのあるシンプルなウェブサイト [Canva](/recommends/canva)はソーシャルグラフィックやシンプルなデザインに十分だ。 ## よくある間違い 1. **すべての人にアピールしようとする。** "起業家"に書くなら、誰にも書いていないのと同じだ。 2. **配信なしで発信する。** 投稿を書いてトラフィックを待つのは戦略ではない。 3. **毎四半期フォーカスを変える。** パーソナルブランドのモメンタムの最大の破壊者。 4. **バニティメトリクスを測定する。** いいね数ではなく、リストのサイズとコンバージョン率を測定しよう。 5. **"十分な専門家"になるまで待つ。** あなたのトピックで世界的な権威である必要はない。 ## パーソナルブランドスタック - **メールプラットフォーム:** [ConvertKit](/recommends/convertkit) - **SEOリサーチ:** [Semrush](/recommends/semrush) - **コンテンツ作成:** [Claude](/recommends/claude) - **デザイン:** [Canva](/recommends/canva) ## FAQ ### パーソナルブランドを構築するにはどれくらいかかるか? 現実的には、意味のあるインバウンドが生まれるまで12〜24ヶ月の一貫した発信が必要だ。 ### すべてのソーシャルプラットフォームにいる必要があるか? いいえ。一つのプラットフォームでの深さは、五つでの浅い存在感より優れている。 ### コンテンツの質と発信頻度はどちらが重要か? 両方だが、同等ではない。質は下限を設定する。頻度は改善に必要な反復を得られるかを決める。 ### 本名とブランド名のどちらを使うべきか? 本名を使おう。実在する人物に紐づいたパーソナルブランドはアルゴリズムの変化をより良く生き延びる。 ### パーソナルブランドをどう収益化するか? 四つの確実な方法:(1) コース/デジタルプロダクト、(2) コンサルティングとアドバイザリー、(3) アフィリエイトパートナーシップ、(4) スポンサードコンテンツ。 --- **関連記事:** [ビジネスアイデアを構築する前に検証する方法](/how-to-validate-a-business-idea/) · [ゼロからメールリストを構築する方法](/how-to-build-an-email-list/) · [ニュースレターを収益化する方法](/how-to-monetize-a-newsletter/) --- ## AIエージェントにメモリを追加する方法:本番環境における状態永続化パターン Source: https://alejandrorioja.com/ja/how-to-add-memory-to-an-ai-agent/ Published: 2026-06-30 Tags: AI Agents TL;DR: ステートレスなエージェント——Workerが終了するとすべてを忘れるタイプ——は1回限りのタスクには適しています。エージェントが昨日何が起きたかを覚えておく必要がある、リピーターの顧客を認識する必要がある、あるいは以前の出力に基づいて作業する必要があるとき、メモリが必要です。3つのパターンがあります:ワーキングメモリ(実行中のコンテキスト、1回の実行期間中KVに保存)、エピソードメモリ(何が起きたか、いつ起きたか、クエリ可能なログ)、セマンティックメモリ(あなたが知っていること、ベクトル検索や構造化データで取得)。正しいパターンを正しいジョブに対応させましょう。 ## 目次 _2026年6月更新。_ **TL;DR:** ステートレスなエージェント——Workerが終了するとすべてを忘れるタイプ——は1回限りのタスクには適しています。エージェントが昨日何が起きたかを覚えておく必要がある、リピーターの顧客を認識する必要がある、あるいは以前の出力に基づいて作業する必要があるとき、メモリが必要です。3つのパターンがあります:ワーキングメモリ(実行中のコンテキスト、1回の実行期間中KVに保存)、エピソードメモリ(何が起きたか、いつ起きたか、クエリ可能なログ)、セマンティックメモリ(あなたが知っていること、ベクトル検索や構造化データで取得)。正しいパターンを正しいジョブに対応させましょう。 **[オペレーターの見解]** ステートレスの壁に何度もぶつかってきました。ソーシャルリプライエージェントは20回会話した顧客に何度も自己紹介し続けました。デイリーブリーフエージェントは昨日すでに報告したことを覚えておらず、同じ問題を4日連続でフラグしました。正しい種類のメモリを追加することで両方を解決しました。これが私が使っている方法です。 ## ステートレスなエージェントがなぜ失敗し続けるのか ステートレスなエージェントは、明示的に渡されたものだけで各実行を開始します:システムプロンプト、ユーザーメッセージ、呼び出し時に取得した新しいデータです。以前の実行、以前のユーザー、以前の決定を認識していません。 1回限りの分類タスク——コメントを読んでカテゴリを返す——にはステートレスで十分です。速く、安く、予測可能です。 継続性が必要になった瞬間に障害が発生します: - 顧客の履歴を認識しない顧客向けエージェント - 先週すでに推薦した記事を推薦するコンテンツエージェント - 解決済みのケースをエスカレートし続けるモデレーションエージェント - 同じ古いアラートを無期限に表示するデイリーブリーフ これらはすべて同じ問題の症状です:エージェントには実行をまたいでコンテキストを運ぶ方法がありません。 ## 3種類のメモリ 本番環境で役立つフレームワーク: 1. **ワーキングメモリ** — 単一の実行中に、エージェントが_今_知っていること。呼び出しの期間中、KVまたはメモリに保持されます。 2. **エピソードメモリ** — 何が起きたか、いつ起きたか。各実行の開始時にエージェントが読んで自分自身を方向付けるための構造化されたログ。 3. **セマンティックメモリ** — 世界、顧客、またはナレッジベースについて知っていること。関連するときに構造化クエリまたはベクトル検索で取得されます。 常に3つすべてが必要なわけではありません。私が実行するほとんどのエージェントはワーキング+エピソードメモリを必要とします。セマンティックメモリは構築が最も難しく、ナレッジベースがコンテキストウィンドウに収まらないほど大きい場合にのみ価値があります。 ## ワーキングメモリ:実行中のコンテキスト ワーキングメモリは、1回のエージェント実行の期間中存在する状態です。最も単純な形は関数スコープ内の変数です。より興味深い形は、同じ実行内のサブタスクが読み書きする共有KVキーです。 私のソーシャルリプライエージェントは、1つのキューメッセージのコメントバッチを処理しながらコンテキストを蓄積するためにワーキングメモリを使用します。開始時に各顧客の最近の会話履歴をKVから読み込み、処理中に新しいコンテキストを追加し、終了時に書き戻します。 ```typescript // workers/social-reply.ts async function processComment( comment: SocialCommentEvent, env: Env ): Promise { // この顧客の最近の履歴をKVから読み込む(ワーキングメモリ) const historyKey = `customer:${comment.userId}:history`; const rawHistory = await env.AGENT_KV.get(historyKey); const history: ConversationTurn[] = rawHistory ? JSON.parse(rawHistory) : []; // 履歴からコンテキスト対応のシステムプロンプトを構築する const systemPrompt = buildSystemPrompt(history); const response = await anthropic.messages.create({ model: "claude-opus-4-8", max_tokens: 512, system: systemPrompt, messages: [{ role: "user", content: comment.text }], }); const reply = response.content[0].type === "text" ? response.content[0].text : ""; // 履歴を更新する——最後の10ターンを保持、TTL 30日間 const updatedHistory: ConversationTurn[] = [ ...history.slice(-9), { role: "assistant", content: reply, timestamp: comment.timestamp }, ]; await env.AGENT_KV.put(historyKey, JSON.stringify(updatedHistory), { expirationTtl: 60 * 60 * 24 * 30, }); await postReply(comment, reply, env); } ``` 2つ注目すべき点があります。履歴は10ターンに制限されています——スライディングウィンドウを挿入し、無制限に増やさないでください。TTLは30日間です:顧客が1ヶ月沈黙すれば、履歴が期限切れになり、エージェントが最初からやり直します。どちらも意図的です。 ## エピソードメモリ:何が起きたか、いつ起きたか エピソードメモリはエージェントのログです。各新しい実行の開始時にエージェントが読んで繰り返しを避けるための過去の実行の構造化された記録です。 私のデイリーブリーフエージェントは、各実行がすでにフラグされたものを認識していなかったため、毎日同じ古いアラートを表示していました。解決策:エージェントがブリーフを生成する前に読む過去のアラートの構造化ログです。 ```typescript // workers/daily-brief.ts interface AlertLogEntry { id: string; surfacedAt: string; // ISOタイムスタンプ resolvedAt?: string; summary: string; } async function buildDailyBrief(env: Env): Promise { const [emails, calendar, tasks] = await Promise.all([ fetchOvernightEmails(env), fetchTodayCalendar(env), fetchTopTasks(env), ]); // エピソードメモリを読み込む:すでにフラグされたもの const rawLog = await env.AGENT_KV.get("brief:alert-log"); const alertLog: AlertLogEntry[] = rawLog ? JSON.parse(rawLog) : []; // 最近の未解決のアラートのみにフィルタリング const sevenDaysAgo = new Date( Date.now() - 7 * 24 * 60 * 60 * 1000 ).toISOString(); const recentAlerts = alertLog.filter( (e) => e.surfacedAt > sevenDaysAgo && !e.resolvedAt ); const brief = await synthesizeBrief( { emails, calendar, tasks, recentAlerts }, env ); // この実行でフラグされた新しいアラートでログを更新する const newAlerts: AlertLogEntry[] = brief.newAlerts.map((a) => ({ id: crypto.randomUUID(), surfacedAt: new Date().toISOString(), summary: a, })); const updatedLog = [...alertLog, ...newAlerts].slice(-100); // 最後の100件を保持 await env.AGENT_KV.put("brief:alert-log", JSON.stringify(updatedLog)); await writeToWorkspace(brief.content, env); } ``` エージェントは自分が何を言ったかを知るようになりました。根本的な問題が変わるまで、重複したアラートはブリーフに含まれません。アラートを解決済みとしてマークすると、アクティブリストから消えます。 このパターンは一般化できます:決定、フラグ、または推薦を生成するエージェントはすべてログから恩恵を受けます。ログは安価(KVに数KB)で、見返りは高い(冗長な出力なし)。 ## セマンティックメモリ:あなたが知っていること セマンティックメモリはナレッジベースです。システムプロンプトにすべてを詰め込む代わりに、クエリ時に「Xについて何を知っていますか?」に答えます。 最も単純な形はKVまたはデータベースの構造化ルックアップです。私のPicklerand予約エージェントは確認書を作成する前に顧客プロファイルとコート好みを検索します: ```typescript // workers/booking-agent.ts interface CustomerProfile { userId: string; preferredCourts: string[]; experienceLevel: "beginner" | "intermediate" | "advanced"; specialNotes: string; } async function draftConfirmation( booking: BookingEvent, env: Env ): Promise { // KVから顧客プロファイルを取得する(セマンティックメモリ——事実的な知識) const profileKey = `customer:${booking.userId}:profile`; const rawProfile = await env.AGENT_KV.get(profileKey); const profile: CustomerProfile | null = rawProfile ? JSON.parse(rawProfile) : null; const systemPrompt = profile ? `あなたはパーソナライズされた予約確認書を作成します。この顧客は${profile.preferredCourts.join("、")}を好み、${profile.experienceLevel}レベルのプレイヤーです。${profile.specialNotes}` : "あなたはピックルボール施設の予約確認書を作成します。"; const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 256, system: systemPrompt, messages: [ { role: "user", content: `次の予約の確認書を作成してください:${JSON.stringify(booking)}`, }, ], }); return response.content[0].type === "text" ? response.content[0].text : ""; } ``` より大きなナレッジベース——製品ドキュメント、サポートナレッジベース、コンテキストウィンドウに収まらないほど大きいもの——にはベクトルストアが必要です。ワークフローは:クエリを埋め込み、最も関連性の高いk個のチャンクを取得し、コンテキストに注入します。Cloudflare Vectorizeは、すでにWorkersを使用している場合にこれをネイティブに処理します。より大きなインデックスにはUpstash Vectorを使用しました。選択はスケールによって決まり、原則ではありません。 セマンティックメモリについての正直な注記:3つの中で構築と維持が最も難しいです。インデックスを最新に保つ必要があります。取得品質が変動します。構造化ルックアップ——KV、D1のテーブル——から始め、構造化アプローチで必要なナレッジサーフェスをカバーできない場合にのみベクトル検索に頼りましょう。 ## メモリ意思決定フレームワーク エージェントにメモリを追加する前に、3つの質問に答えましょう: 1. **エージェントは実行をまたいで記憶する必要がありますか?** 各呼び出しが本当に独立している場合——翻訳、分類、1回限りの生成——メモリをスキップしてください。ステートレスはよりシンプルで安価です。 2. **エージェントは自分の履歴に目をつぶって繰り返していますか?** そうなら、まずエピソードメモリを追加しましょう。最も労力の少ない修正であり、「エージェントがXをし続ける」という苦情のほとんどをカバーします。 3. **エージェントはすべきでないのに各ユーザーまたはエンティティを同一に扱っていますか?** そうなら、ワーキングメモリ(顧客履歴、ユーザープロファイル)またはセマンティックメモリ(検索または取得システム)を追加しましょう。 私が最もよく見る間違い:誰かがエピソードメモリがなかったために失敗していたエージェント——すでに何をしたかのログがなかったエージェント——に巨大なナレッジベース(セマンティックメモリ)を追加します。複雑さが問題と一致していません。 ## 本番環境で実際に使っているもの 30以上のエージェントで: - **すべて**が少なくともワーキングメモリを持っています——実行内の何らかの状態の形、たとえそれがコンテキストウィンドウ自体だとしても。 - **約半数**がエピソードメモリを持っています——過去の実行、決定、フラグのログ。これはほぼ常に追加する価値があります。 - **3〜4個**がベクトルストアに支えられた真のセマンティックメモリを持っています。これらは大規模で動的なナレッジベースに対して質問に答えるエージェントです。 Cloudflare KVは、ワーキングメモリとエピソードメモリのデフォルトストレージです。高速で安価で、Workersにネイティブに統合されています——追加のクライアントなし、別の認証情報なし。制限:KVは最終的に一貫性があり、高頻度の書き込みには適していません。エージェントが1秒に何度も状態を書き込む場合は、代わりにDurable ObjectsまたはD1データベースを使います。 ベクトルに支えられたセマンティックメモリには、小〜中規模のインデックス(〜10万ベクトル未満)にCloudflare Vectorizeを、それより大きいものにUpstash Vectorを使用します。どちらも一流のJavaScriptクライアントを持っています。 ## オペレーターの結論 ステートレスな動作が本当の問題を引き起こしているときだけエージェントにメモリを追加しましょう——繰り返しの出力、顧客履歴の盲点、過去の決定への無知。次に、正しいレイヤーを選びましょう:実行中のコンテキストにはワーキングメモリ、過去に起きたことにはエピソードメモリ、知っていることにはセマンティックメモリ。確信が持てない場合はエピソードから始めましょう——最も少ない複雑さで最も一般的な障害モードを修正します。構造化ルックアップを使い切るまでベクトルデータベースに頼らないでください。最良のメモリシステムは、エージェントを正しく動作させる最もシンプルなものです。 --- **関連:** [30以上の本番エージェントを実行するために使用するエージェントスタック](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [イベントトリガー型エージェントとスケジュールエージェント](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [AIエージェントが実際に機能しているかどうかを測定する方法](/how-i-measure-whether-an-ai-agent-is-actually-working/) **あなたのユースケースにエージェントメモリを設計する手助けが必要ですか?** [お問い合わせ](/contact/) — オペレーターチームのための本番エージェントシステムを設計しています。 --- ## メールリストをゼロから構築する方法:2026年プレイブック Source: https://alejandrorioja.com/ja/how-to-build-an-email-list/ Published: 2026-06-27 Tags: Entrepreneurship, Growth TL;DR: メールリストはあなたが本当に所有できる唯一の配信チャンネルです。特定の問題を解決するリードマグネットから始め、オプトインをファーストビューに配置し、誰かが登録した瞬間に3通のウェルカムメールを送りましょう。質は量を常に上回ります — エンゲージした1,000人の読者は、冷たい10,000人を凌ぎます。 ## 目次 _2026年6月更新。_ **TL;DR:** メールリストはあなたが本当に所有できる唯一の配信チャンネルです。特定の問題を解決するリードマグネットから始め、オプトインをファーストビューに配置し、誰かが登録した瞬間に3通のウェルカムメールを送りましょう。質は量を常に上回ります — エンゲージした1,000人の読者は、冷たい10,000人を凌ぎます。 **[オペレーターの視点]** 私が関わってきた持続可能な収益エンジンを構築したすべてのビジネスには、共通点が一つありました:リストです。フォロワーではありません。インプレッションでもありません。あなたから話を聞きたいと申し出た人々のリストです。ゼロから構築する方法をここで説明します。 ## 本当に所有できる唯一の資産 他のすべての配信チャンネルは消えてしまう可能性があります。Googleのアルゴリズム更新が検索順位を消し去ります。プラットフォームのポリシー変更がFacebookのリーチを殺します。広告アカウントが警告なく停止されます。 メールリストはその例外です。メールリストを所有すれば、配信をコントロールできます。あなたのコンテンツを誰が見るかを決めるアルゴリズムはありません。オーディエンスにリーチするたびに料金を徴収するプラットフォーム手数料もありません。 これが、メールリストの構築を私がすべての創業者に最初に伝えることの理由です — SEOより前に、有料広告より前に、ソーシャルメディアより前に。 ## ステップ1:メールプラットフォームを選ぶ アドレスを1件収集する前に、保存・送信するためのプラットフォームが必要です。Gmailは使わないでください。ビジネスメールは使わないでください。適切なコンプライアンスと配信インフラを持つ専用ツールを使用してください。 2026年の私の2つの選択: **[ConvertKit](/recommends/convertkit)** — クリエイターとソロオペレーターに最適。サブスクライバーのタグ付けとセグメンテーションシステムが本当に優秀です。1,000人のサブスクライバーまで無料。 **[Moosend](/recommends/moosend)** — ConvertKitの価格なしで自動化を望む中小企業に最適。しっかりしたドラッグ&ドロップビルダーと一貫して良好な配信率。 ゼロから始める場合、両方とも最初の数百人のサブスクライバーをカバーする無料プランがあります。何かを送信する前に、ドメインでDKIM、SPF、DMARCの認証を設定してください — これは2024年からGmailとYahooによって大量送信者に義務付けられており、初日から送信者の評判を守ります。 ## ステップ2:ダウンロードする価値のあるリードマグネットを作る リードマグネットとは、誰かのメールアドレスと引き換えに提供するものです。多くの人が犯す間違い:汎用的なものを提供すること。 「ニュースレターを購読する」はリードマグネットではありません。何も返さない信頼の要求です。 リードマグネットは特定の人の特定の問題を解決する必要があります。より具体的なほど、より良くコンバートします。 **2026年に機能するフォーマット:** 1. **チートシートとテンプレート** — 誰かがすぐに使える1ページのリソース。プラグアンドプレイであるほど良い。 2. **ミニコース(3〜5通のメール)** — 1つのスキルを教える短いシーケンスで、自動配信されます。リストと関係を同時に構築します。 3. **計算ツールまたはスプレッドシート** — 高い知覚価値。市場規模算定ツール、価格モデル、予算テンプレート。実際の作業を節約するのでコンバートします。 4. **限定データまたはリサーチ** — オリジナルの調査結果またはベンチマークレポート。再現が難しく、高い信頼性。 5. **スワイプファイル** — 実際の例の集まり(広告コピー、件名、ランディングページの見出し)。実務家はこれに対価を払います。 6. **ウェビナーまたはトレーニングの録画** — 既存の録画をオプトインとして再利用します。セットアップに20分かかります。 絶対に譲れない条件:リードマグネットは、メールで伝える内容と直接関連している必要があります。B2B SaaSニュースレターのためにサブスクライバーを獲得するFacebook広告テンプレートは、リスト品質の災害が待ち構えています。 ## ステップ3:オプトインフォームを効果的な場所に配置する フォームの配置は、コピーよりもコンバージョンを促進します。すでに注意が向いている場所にオプトインフォームを置きましょう: 1. **ホームページのファーストビューより上** — フッターではありません。サイドバーでもありません。ファーストビューより上に、彼らが得るものの明確な説明とともに。 2. **すべてのブログ記事の末尾** — 記事全体を読んだ人は事前に資格を持っています。まだエンゲージしている間に捕まえましょう。 3. **離脱意図ポップアップ** — 訪問者がタブを閉じようとしたときにトリガーされます。賛否があるが機能します。 4. **専用ランディングページ** — ナビゲーションのないスタンドアロンページ。ここに有料トラフィックを送ります。 5. **コンテンツアップグレード** — 特定の投稿を強化するリソース。TAM/SAM/SOMガイド内の市場規模算定スプレッドシートは、同じページの汎用オファーより3〜5倍高くコンバートします。 コピーのヒント:フォーマットではなく、アウトカムから始めましょう。「5ページガイドを入手する」は「VCのように市場規模を把握する」より弱いです。 ## ステップ4:ウェルカムシーケンスを書く 誰かが登録した瞬間、あなたは彼らの最大の注意を持っています。それを沈黙で無駄にしないでください。 最低3通のメールを送ってください: **メール1(即時):** リードマグネットを届けてください。彼らが登録したものを確認してください。今後の期待を設定してください。 **メール2(2日目):** あなたの最高のコンテンツ — 投稿、ケーススタディ、フレームワーク。ピッチはなし。登録する価値があったという証明だけ。 **メール3(4〜5日目):** あなたの起源の話と視点。なぜこのトピックに関心があるのですか?あなたの分野のほとんどの人が信じていないが、あなたが信じることは何ですか?ここで信頼が構築されます。 そこから、一貫したケーデンスを維持しましょう。週1回が標準です。品質を週1回維持できない場合は隔週でも機能します。最悪の間違いは、ローンチ時に1回メールして、その後3ヶ月間消えることです。 ## ステップ5:オプトインにトラフィックを誘導する トラフィックのないフォームは誰もコンバートしません。最も信頼性の高い成長チャンネル: **オーガニック検索** — リードマグネットが解決する問題のためにランクインするブログ投稿。あなたのトピックを検索して投稿を見つける人は、あなたのオファーに対して事前に資格を持っています。これは最もコストが低く、保持率が最も高いチャンネルです。 **ソーシャルメディア(オーガニック)** — LinkedIn投稿、Twitter/Xスレッド、またはショートフォームビデオで人々をオプトインページに誘導します。すべての投稿はティーザーであるべきで、完全な話ではありません。 **ニュースレタースワップとコプロモーション** — 隣接するスペースのニュースレターを見つけ、メンションを交換します。あなたが彼らのリストを宣伝し、彼らがあなたのリストを宣伝します。これは500から5,000人のサブスクライバーに成長する最も速い方法の一つです。 **ポッドキャストゲスト出演** — 過小評価されています。2,000人のニッチリスナーに送られた30分のエピソードは、あなたが送るすべてのメールを開封する可能性が高い50〜100人の深く興味を持つサブスクライバーを追加できます。 **有料広告** — 未検証のオファーに広告を出さないでください。まずオプトインページをオーガニックにコンバートさせてから、有料トラフィックでスケールアップしましょう。 ## ステップ6:リストを清潔に保つ メールリストは劣化します。人々は仕事を変え、メールアドレスを変え、興味を変えます。リストを清掃しないと、配信率が低下します — これはエンゲージしたサブスクライバーもメールを見なくなることを意味します。 ベストプラクティス: - **6ヶ月ごとに再エンゲージメントキャンペーン** — 90日以上開封していない人に全員メールを送ります。残る理由を与えてください。エンゲージしない場合は削除してください。 - **ハードバウンスはすぐに削除** — 高いバウンス率は、メールプロバイダーにリストが汚れていることを示します。 - **エンゲージメント別にセグメント** — アクティブと冷たいサブスクライバーに別々にタグ付けします。時間に敏感なキャンペーンはアクティブセグメントだけに送ります。 サブスクライバーを削除することは何かを失うように感じます。実際には、保持したいサブスクライバーを保護することになります。 ## 正直な注意点 **構築には時間がかかります。** オーガニックな方法だけでゼロから始めると、1,000人のサブスクライバーに到達するまで3〜6ヶ月かかることを想定してください。数週間で数千人を約束する人は、バニティメトリクスや欲しくない冷たい、エンゲージしていない連絡先を売っています。 **ニッチが重要です。** B2Bオーディエンスはデータとケーススタディに反応します。消費者オーディエンスは割引とエンタメに反応します。リードマグネットとコンテンツのケーデンスはオーディエンスに合わせる必要があります。 **リードマグネットは古くなります。** 今日よくコンバートするものは、競合他社がフォーマットをコピーすると18ヶ月で時代遅れになる可能性があります。毎年リードマグネットを更新することを計画してください。 ## 現実的なベンチマーク | 指標 | 業界平均 | 良い | |--------|-----------------|------| | ポップアップオプトイン率 | 2〜4% | 5〜8% | | ランディングページオプトイン率 | 20〜30% | 40〜60% | | ウェルカムメール開封率 | 50〜60% | 70%+ | | 継続的な開封率 | 20〜25% | 35〜45% | | クリック率 | 2〜3% | 5〜10% | 最初の90日間はこれらの数字を最適化しないでください。インフラを構築し、リードマグネットを実行し、一貫して送信します。その後、繰り返します。 ## 2026年6月更新 **AI生成リードマグネット** — Claudeのようなツールは、10ページのPDFガイド、スワイプファイル、またはテンプレートを数分で作成できます。高品質なリードマグネットを作成する障壁はほぼゼロです。差別化要因は今、約束の具体性とオーディエンスへの関連性です。 **GmailとYahooの認証** — 2024年以降、1日に1,000件以上のアドレスにメールを送る送信者にはDKIM、SPF、DMARCが必要です。[ConvertKit](/recommends/convertkit)と[Moosend](/recommends/moosend)はどちらもオンボーディング中にセットアップをガイドします。必要になる前にやっておきましょう。 **AI検索トラフィック** — 明確なTL;DRと検索クエリへの直接回答を含む、よく構造化されたオプトインページは、ChatGPT、Perplexity、Google AI Overviewsに表示される可能性があります。オプトインランディングページがSEO作業なしでAI検索から一貫したトラフィックを得るのを見てきました — ページが特定の質問に直接答えているからです。 ## よくある質問 **収益化するために何人のサブスクライバーが必要ですか?** 普遍的な数字はありません。高い意図のニッチで500人の深くエンゲージしたサブスクライバーを持つニュースレターが、20,000件の汎用連絡先のリストを上回るのを見てきました。問題はサブスクライバーが問題を持っているかどうか、そして彼らがあなたがそれを解決することを信頼するかどうかです。 **メールリストを購入すべきですか?** いいえ。購入したリストはエンゲージメントが最悪で、スパムとしてフラグを立てられ、アカウントを停止させる可能性があります。近道はありません。 **どのくらいの頻度でメールを送るべきですか?** 品質を維持しながら可能な限り頻繁に。週1回が心に残ります。最大の間違いは、数ヶ月間沈黙して、売り込みで戻ってくることです。 **ダブルオプトインかシングルか?** ほとんどの場合ダブルオプトイン。確認によってリストサイズが縮小しますが、エンゲージメントと配信率が劇的に向上します。例外は、特定のソースから高い意図の検証済みトラフィックを誘導している場合です。 **初心者に最適なメールプラットフォームは何ですか?** 個人ブランドまたはコンテンツビジネスを構築するクリエイターには[ConvertKit](/recommends/convertkit)。手頃な価格と自動化を望む中小企業には[Moosend](/recommends/moosend)。どちらもGmailを使おうとするよりはるかに優れています。 ## 次にどこへ向かうか メールリストは孤立して存在するわけではありません。最もパフォーマンスの良い投稿にはコンテンツアップグレードが必要です。メールは詳細なガイドへのリンクを設けるべきです。リードマグネットは、最もトラフィックの多いページが対応している正確な問題を解決する必要があります。 そのループ — トラフィック → オプトイン → ナーチャリング → 信頼 → オファー — は、私が関わってきたすべての持続可能なオンラインビジネスの基盤です。 あなたの具体的な状況についてどう対処するかを話し合いたい場合は、[コンタクトページ](/contact)が始めるのに適した場所です。 --- ## ニュースレターを収益化する方法:本当に機能する5つの収益モデル Source: https://alejandrorioja.com/ja/how-to-monetize-a-newsletter/ Published: 2026-06-25 Tags: Entrepreneurship, Growth TL;DR: ほとんどのニュースレターがマネタイズに失敗する理由は、リストサイズに合わないモデルを追い求めているからです。実際に機能する5つのモデル:有料購読(ニッチな権威構築に最適)、スポンサーシップ(5,000人以上のサブスクライバー獲得後に最適)、アフィリエイト推薦(どのサイズでも最もハードルが低い)、コースとプロダクトファネル(最高の収益上限)、サービスのアップセル(最も早く実収益を得る方法)。まず1つから始める。最初のモデルが機能してから、2つ目を追加する。 ## Table of contents _2026年6月更新。_ **TL;DR:** ほとんどのニュースレターがマネタイズに失敗する理由は、リストサイズに合わないモデルを追い求めているからです。実際に機能する5つのモデル:有料購読(ニッチな権威構築に最適)、スポンサーシップ(5,000人以上のサブスクライバー獲得後に最適)、アフィリエイト推薦(どのサイズでも最もハードルが低い)、コースとプロダクトファネル(最高の収益上限)、サービスのアップセル(最も早く実収益を得る方法)。まず1つから始める。最初のモデルが機能してから、2つ目を追加する。 **[オペレーターの視点]** 私は「ニュースレタービジネス」と呼ばれる前からニュースレターを運営しています。正直に言うと、最初はすべてを一度にやろうとして、ほとんど稼げませんでした。1つのモデルに絞り込んでから、ようやく収益が出始めました。ここでは私が学んだことと、一緒に仕事をするオペレーターたちが安定して成果を出している方法を共有します。 ## ほとんどのニュースレターがなぜ1円も稼げないのか マネタイズの問題は、多くの場合、順序の問題です。ニュースレターを立ち上げ、ゆっくり成長させ、その後一度にすべての収益ストリームを追加しようとします——有料ティアをここに、スポンサースロットをあそこに、毎号アフィリエイトリンクを。結果は、ショッピングモールのようなニュースレターです。すべてが売り物で、何も本物に感じられず、読者が離れていきます。 安定して稼ぐニュースレターは、まず1つのことをうまくやります。特定のオーディエンスに対して1つのモデルが機能することを証明してから、初めて2つ目を加えます。 リストサイズもどのモデルが実現可能かを決定します。500人のサブスクライバーリストは、スポンサーを探すための間違ったツールです。50,000人のサブスクライバーリストも、アフィリエイトリンクだけを使っているなら多大な収益機会を逃しています。モデルはリストに合わせる必要があります。 ## モデル1:有料購読 **最適:** 明確な専門的または高い関心を持つオーディエンスを持つニッチな権威ニュースレター。 有料購読はニュースレターマネタイズの最も純粋な形態です:読者がコンテンツに対して直接支払います。BeehiivやSubstackなどのプラットフォームにより、無料リストに簡単に追加できます。 機能するための条件: - 情報が希少または時間を節約できる特定の高価値ニッチ(財務分析、業界インテリジェンス、オペレーターレベルの戦術) - 「支払うとサブスクライバーは無料では得られない何を受け取るのか?」への明確な答え - 本当に価値ある無料ティア——希薄化されたバージョンではなく、有料ティアのアプローチの味見 失敗の原因: - 緊急性の低い一般的なトピック(「マーケティングのヒント」「自己啓発」) - 無料サブスクライバーが継続的にコンテンツを読んでいることを証明する前に有料を立ち上げる 現実的な収益:サブスクライバー1人あたり月500〜2,000円。2,000人のリストから5%のコンバージョンで、月1,000円の有料サブスクライバー100人 = 月10万円MRR。小さいですが、実在し、積み上がります。 ## モデル2:スポンサーシップとネイティブ広告 **最適:** 5,000人以上のサブスクライバーと定義されたオーディエンス層を持つニュースレター。 スポンサーシップは最も目立つモデルです——オーディエンスに関連するブランドに号枠を販売します。うまくいけば、効果的です:ニッチなB2Bまたはハイインカムオーディエンスでは$100〜$500+のCPM(千人あたりコスト)が一般的です。 正直な制約:スポンサーはスケールと具体性を求めます。「マーケティングに興味のあるサブスクライバー1,000人がいます」では取引が成立しません。「従業員10〜500人の企業のマーケティングマネージャー6,000人がサブスクライバーで、開封率52%」であれば成立します。 そこに到達する方法: 1. **オーディエンスを定義する** 興味の言葉ではなく、人口統計的な言葉で 2. **5,000人のサブスクライバーに達する** スポンサーをピッチングする前の最低限の信頼性の基準として 3. **エンゲージメントを証明する** — 40%以上の開封率が本物の差別化要因 4. **メディアキットを作成する** — サブスクライバー数、開封率、オーディエンスプロフィール、スポンサーシップパッケージを含む1ページのPDF 5. **インバウンドから始める** — アウトバウンド販売プロセスを構築する前にスポンサーシップマーケットプレイスにリストする CPM現実チェック:リストが45%の開封率でコンバートし、$200 CPMで号ごとに1つのスポンサースロットを販売した場合、5,000人のサブスクライバーリストはスポンサー号ごとに$1,000を生成します。月4号で1つのスポンサースロットから月$4,000。2つのスロットで月$8,000。数学はスケールで機能します。 ## モデル3:アフィリエイト推薦 **最適:** あらゆるリストサイズ、ツールやサービスを本当に使用しているあらゆるニッチ。 アフィリエイトマーケティングは始めるための最低ハードルモデルです:実際に使っている製品を推薦し、読者がクリックし、購入でコミッションを得ます。管理するスポンサー関係なし、構築するプロダクトなし、維持する有料ティアなし。 重要な制約は信頼です。アフィリエイト推薦は、推薦が本当に役立ち、信頼性のある情報源から来ている場合にのみコンバートします。使ったことのない製品でいっぱいの「トップピック」セクションはアンダーパフォームするか、さらに悪い場合はリストを傷つけます。 機能するもの: - 自分のスタックで使っているツールを推薦する(私の場合:メール管理に[ConvertKit](/recommends/convertkit)、SEOとコンテンツ調査に[Semrush](/recommends/semrush)) - コンテキスト的な配置 — コンテンツに関連する場所でツールに言及し、読者がスキップするように訓練された固定の「この号のスポンサー」ブロックでは言及しない - 本当の意見を述べる:好きなこと、好きでないこと、誰に向いていないか 収益上限:アフィリエイトコミッションは様々 — SaaSツールは通常、コンバートされたサブスクライバーに対して20〜40%を継続的に支払い、うまく積み上がります。1,000人のサブスクライバーリストで読者の2%が月$50のSaaSに30%のコミッションでコンバートした場合 = 継続的に月$300、残り続ける新規サインアップとともに成長します。 ## モデル4:コースとデジタルプロダクトのファネル **最適:** 特定のドメインで教育的権威を持つオペレーター。 ニュースレターはファネルの上部です;コースまたはデジタルプロダクトがコンバージョンイベントです。毎号を開封するほどあなたを信頼している読者は、あなたが知っていることを教える有料プロダクトに対する最も資格の高いリードです。 これは控えめなリストでも最高の収益上限を持つモデルです。5,000人のリストの2%に$497のコースを販売すると、1回のローンチで$49,700です。リストが成長しながら年3回のローンチで積極的に積み上がります。 必要なもの: - 特定のドメインでの本物の教育的権威 — 単に「マーケティングを知っている」ではなく「この特定のグロースプレイブックを使って3つのB2B企業を成長させた」 - 週ごとに権威を示すコンテンツ(キュレートされたリンクだけでなく — あなたオリジナルのフレームワークとケーススタディ) - リストが準備されてきたローンチシーケンス — コンテンツだけを受信するリストへの冷たい「私のコースを買ってください」メールではない これは私が自分の仕事で最も頼るモデルです。ニュースレターが信頼を構築し、コースがそれをコンバートします。 ## モデル5:サービスのアップセル **最適:** オペレーターがコンサルティング、コーチング、またはDone-for-youサービスを提供する初期段階のニュースレター。 このモデルは小さなリストサイズで最も早く実収益を得る方法であり、最も過小利用されています。ニュースレターがあなたをエキスパートとして位置づけ;サービスが仕事をするエキスパートです。 500人がグロースマーケティングに関するあなたのニュースレターを読み、月1号あなたの思考を示す号を発行すると、その500人の読者のうち1〜2人が定期的に手を挙げ、コンサルティングをしているかどうか尋ねます。提供しなければ、収益を逃しています。 明示的にする方法: - ニュースレターのフッターにこの一文を追加する:「私は四半期ごとに少数のクライアントと[特定の成果]について取り組んでいます。探ってみたい場合はこのメールに返信してください。」 - 関連する号でクライアントの成果(匿名化)に言及する — 自慢としてではなく、フレームワークが実際に機能することの証拠として - キャパシティを意図的に限定的に保つ — ここでの希少性は作られたものではなく、実際のものです;あなたの時間は限られています 収益の現実:月$5,000のコンサルティングクライアント1人と200人のニュースレターは、散在するアフィリエイト収入で1サブスクライバーあたり$0.01を稼ぐ50,000人のサブスクライバーよりも優れた経済性を持っています。ここから始めるためにスケールを待たないでください。 ## 正しいモデルの選び方 決定フレームワーク: | リストサイズ | 最良の開始モデル | 追加する2番目のモデル | |------------|----------------|-------------------| | 0〜1,000 | サービスのアップセル | アフィリエイト推薦 | | 1,000〜5,000 | アフィリエイト + コース待機リスト | 有料購読 | | 5,000〜20,000 | スポンサーシップ | コースローンチ | | 20,000+ | スポンサーシップ + コース | 有料ティア | どのサイズでも変わらない制約が1つあります:最初に1つを選んでください。モデルの乱立は、すべてのモデルのコンバージョンを同時に損ないます。 ## ニュースレターオペレーターのスタック ニュースレタービジネスを構築するために私が使い、推薦するツール: - **メールプラットフォーム:** [ConvertKit](/recommends/convertkit) — バイヤーとリーダーを分けるサブスクライバータグ付け、セグメント化、オートメーションシーケンス - **SEOとトピック調査:** [Semrush](/recommends/semrush) — ターゲットオーディエンスが検索しているものをコンテンツを書く前に特定する - **デザイン:** [Canva](/recommends/canva) — デザイナーなしでメディアキット、コースカバーアセット、ソーシャルコンテンツを作成 - **支払い:** Stripe — 有料購読ティアまたはコースチェックアウト用 ## オペレーターの結論 ニュースレターは2026年に構築できる最もレバレッジの高いコンテンツ資産です:メール受信トレイへの注意は、ソーシャルフィードが持ち得ない方法で希少で価値があります。しかし、資産が収益に変わるのは、リストサイズに合ったモデルを選び、本物の推薦と本物の権威を持って実行し、一度にすべてのマネタイズ方法に散らばる衝動に抵抗する場合だけです。 今日の自分の状況に合ったモデルから始めてください。それが機能したら——安定して、積み重なる結果を持って——次のものを追加してください。 --- **関連:** [ビジネスアイデアを構築する前に検証する方法](/how-to-validate-a-business-idea/) · [グロースマーケティング戦略ガイド](/growth-marketing-strategies-guide/) · [中小企業のための6つの最高のメールマーケティングサービス](/6-best-email-marketing-services-for-small-business/) --- ## はじめてのMCPサーバーの作り方:実践ガイド Source: https://alejandrorioja.com/ja/how-to-build-your-first-mcp-server/ Published: 2026-06-23 Tags: AI Agents TL;DR: MCP(Model Context Protocol)は、コンテキストウィンドウを圧迫せずに、データベース、ファイル、APIなどの外部ツールやデータへの構造化されたアクセスをClaudeに与える方法です。サーバーは見た目より簡単です:SDKをインストールし、ツールをJSONスキーマとして定義し、ハンドラーを実装し、stdioで接続します。30分以内にClaudeがカスタムツールを呼び出せるようになります。 ## 目次 _2026年6月更新。_ **TL;DR:** MCP(Model Context Protocol)は、コンテキストウィンドウを圧迫せずに、データベース、ファイル、APIなどの外部ツールやデータへの構造化されたアクセスを[Claude](/recommends/claude)に与える方法です。サーバーは見た目より簡単です:SDKをインストールし、ツールをJSONスキーマとして定義し、ハンドラーを実装し、stdioで接続します。30分以内にClaudeがカスタムツールを呼び出せるようになります。 **[オペレーターの視点]** 私は定期的にエージェントに新しいツールを組み込んでいます。MCPは今やそれをクリーンに行うための標準的な方法です。サーバーを一度構築すれば、MCP対応のすべてのクライアント——Claude Desktop、Claude Code、Anthropic SDKを使用するすべてのアプリ——が呼び出し側のコードを変更せずに使用できます。これが価値です:一度作って、どこでも再利用する。 ## MCPとは何か **Model Context Protocol**は、AIモデルが外部コンテキストとツールに接続する方法を標準化するオープンプロトコルです。AIインテグレーションのUSB-C規格と考えてください:以前は、Claudeにデータベースを読ませたりAPIを呼び出させたりしたいアプリは、それぞれ独自の仕組みを考える必要がありました。MCPを使えば、MCPサーバーを一つ作るだけで、準拠するすべてのホストが使用できます。 MCPはサーバーが提供できる3つのものを定義します: - **ツール**——Claudeが呼び出せる関数(ファイルを読む、DBをクエリする、Slackメッセージを送る) - **リソース**——Claudeが読めるデータ(ドキュメント、データベースの行、ファイルツリー) - **プロンプト**——ホストが挿入できる再利用可能なプロンプトテンプレート ほとんどのオペレーターユースケースでは、**ツールサーバー**を構築します。リソースとプロンプトは基本が動いてから後で対応します。 アーキテクチャはクライアント-サーバーで、クライアント(Claude Desktop、Claude Code、カスタムアプリ)がすべてを制御します。サーバーは受動的——ツール呼び出しリクエストを待ち受けて結果を返すだけです。 ## すべてのMCPサーバーの3つの部品 構築するMCPサーバーはすべて同じ構造を持ちます: 1. **サーバーオブジェクト**——サーバーの名前、バージョン、提供する機能(ツール、リソース、プロンプト)を宣言 2. **ツール定義**——名前、説明、入力のJSONスキーマを持つツールのリスト 3. **リクエストハンドラー**——Claudeがツールを呼び出したときに実行される関数 それだけです。開始時にデータベース、HTTPスタック、auth層は不要です。最小サーバーは30行未満のTypeScriptです。 ## 前提条件(2分) - **Node.js 18+**——`node --version`で確認 - **TypeScript 5+**(下記でdev dependencyとして含む) - テスト用のMCPクライアント——Claude Desktopは無料で、サーバーの動作を確認する最も簡単な方法 MCPサーバーを実行するためにAnthropic APIキーは不要です。APIキーはクライアント(Claude Desktop)にあり、サーバーにはありません。 ## ステップ1:プロジェクトのセットアップ(3分) ```bash mkdir my-mcp-server && cd my-mcp-server npm init -y npm install @modelcontextprotocol/sdk npm install -D typescript tsx @types/node ``` `package.json`に追加: ```json { "type": "module", "scripts": { "build": "tsc", "dev": "tsx src/index.ts" } } ``` `tsconfig.json`を作成: ```json { "compilerOptions": { "target": "ES2022", "module": "Node16", "moduleResolution": "Node16", "outDir": "./build", "strict": true }, "include": ["src/**/*"] } ``` ## ステップ2:最小サーバーを書く(5分) `src/index.ts`を作成: ```typescript import { Server } from "@modelcontextprotocol/sdk/server/index.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { CallToolRequestSchema, ListToolsRequestSchema, } from "@modelcontextprotocol/sdk/types.js"; const server = new Server( { name: "my-mcp-server", version: "1.0.0" }, { capabilities: { tools: {} } } ); // このサーバーが提供するツールを宣言 server.setRequestHandler(ListToolsRequestSchema, async () => ({ tools: [ { name: "get_word_count", description: "テキストブロックの単語数を数えます。", inputSchema: { type: "object", properties: { text: { type: "string", description: "単語を数えるテキスト", }, }, required: ["text"], }, }, ], })); // クライアントからのツール呼び出しを処理 server.setRequestHandler(CallToolRequestSchema, async (request) => { const { name, arguments: args } = request.params; if (name === "get_word_count") { const { text } = args as { text: string }; const count = text.trim().split(/\s+/).filter(Boolean).length; return { content: [{ type: "text", text: `単語数:${count}` }], }; } throw new Error(`不明なツール:${name}`); }); // stdioで接続——Claude DesktopがサーバーとやりとりするEways const transport = new StdioServerTransport(); await server.connect(transport); ``` これが完全なサーバーです。1つのツール(`get_word_count`)を登録して実装します。構造が重要です。 ## ステップ3:ビルドしてClaude Desktopに登録(5分) TypeScriptをビルド: ```bash npm run build ``` Claude Desktopの設定ファイルに登録します。 **macOS**:`~/Library/Application Support/Claude/claude_desktop_config.json` **Windows**:`%APPDATA%\Claude\claude_desktop_config.json` ファイルが存在しない場合は作成: ```json { "mcpServers": { "my-mcp-server": { "command": "node", "args": ["/absolute/path/to/my-mcp-server/build/index.js"] } } } ``` 絶対パスを使用します。保存後にClaude Desktopを再起動します。メッセージ入力にハンマーアイコン(🔨)が表示されれば、Claudeがあなたのツールをdiscoverしたサインです。 ## ステップ4:便利なツールを作る 単語カウントは説明用です。より便利なツールを紹介します:プロジェクトディレクトリからファイルを読む——コードベース、changelog、設定ファイルを要約するコンテキスト注入エージェントに使用しているものです。 ```typescript import { readFileSync, readdirSync } from "fs"; import { join, extname } from "path"; const ALLOWED_EXTENSIONS = [".md", ".txt", ".ts", ".json", ".yaml"]; const PROJECT_DIR = process.env.PROJECT_DIR ?? process.cwd(); ``` ロジックは同じです:正確なJSONスキーマでツールを定義し、ハンドラーを実装し、パストラバーサルを防ぐために入力を検証し、クライアントにテキストを返します。 ## 私がはまった落とし穴(あなたがはまらないように) **パスは絶対パスでなければなりません。** Claude Desktop設定の相対パスは期待通りに解決されません。常に完全パス `/home/user/...` を使用してください。 **stdioはサーバーで`console.log`を使えないことを意味します。** Claude Desktopはstdin/stdoutを通じてサーバーと通信します。デバッグの`console.log`はJSON-RPCストリームを破壊します。代わりにstderrにログ: ```typescript process.stderr.write(`デバッグ:${message}\n`); ``` **設定変更のたびにClaude Desktopを再起動してください。** MCPサーバーは起動時に読み込まれます。編集した設定ファイルはアプリを閉じて再度開くまで何もしません。 **ツールの説明がプロダクトです。** Claudeは`description`フィールドに基づいてツールを呼び出すかどうか決めます。曖昧な説明はClaudeがいつ使うべきか分からないことを意味します。正確な説明はClaudeが適切なタイミングでそれを使うことを意味します。実装よりも説明に時間をかけてください。 ## 本番環境でのMCPサーバーの使い方 stdioパターンはClaude DesktopとClaude Code(ローカル)に最適です。本番エージェント——[Cloudflare Workersで実行している30以上](/the-agent-stack-i-use-to-run-30-production-agents-no-python/)——では、ステップごとに[HaikuとSonnet](/ai-agent-cost-math-when-haiku-beats-sonnet)にルーティングする柔軟性が必要なため、Anthropic SDKのtool-use APIを直接使用します。 実際に使っているパターン: 1. **ローカル開発ツール**——プロジェクト固有のツールを公開するClaude Code用MCPサーバー 2. **コンテキスト注入**——手動コピーなしに関連ドキュメントをプリロードするMCPサーバー 3. **プロトタイプからAPIへのブリッジ**——MCP を先に構築し(イテレーションが速い)、その後ロジックをSDK tool-useに移植 ## 次に作るもの サーバー構造が理解できたら、有用なツールはClaudeの外部コンテキストにアクセスするものです: - **データベースリーダー**——読み取り専用SQLクエリを実行してJSONとして結果を返す - **Slackリーダー**——チャンネルから最新N件のメッセージを取得 - **GitHubリーダー**——オープンPRをリスト、特定のコミットのファイルを読む - **内部APIラッパー**——認証ヘッダーを組み込んで自分のREST APIを呼び出す ## よくある質問 ### MCPサーバーを構築するにはAnthropic APIキーが必要ですか? いいえ。MCPサーバーはAnthropic APIを呼び出しません。クライアントからのツール呼び出しリクエストに応答するだけです。APIキーはクライアントにあり、サーバーにはありません。 ### MCPサーバーは外部APIを呼び出せますか? はい——ハンドラーは単なる非同期TypeScriptコードです。天気APIをフェッチし、データベースをクエリし、ファイルに書き込む。サーバーはハンドラーが内部で何をするかを気にしません。 ### stdioとHTTPトランスポートの違いは何ですか? stdioはローカルサーバー用——Claude DesktopやClaude Codeと同じマシン。HTTP with SSEはWebサービスとしてデプロイできるリモートサーバー用。stdioから始めてください;デバッグが簡単です。 ### Claudeはいつ自分のツールを呼び出すべきか知っていますか? Claudeはツールの`description`フィールドと会話のコンテキストに基づいて決定します。Claudeがツールを無視し続ける場合は、説明を絞り込んでください。 --- ## ビジネスアイデアを構築する前に検証する方法 Source: https://alejandrorioja.com/ja/how-to-validate-a-business-idea/ Published: 2026-06-20 Tags: Entrepreneurship, Growth TL;DR: ほとんどのビジネスアイデアは、実行が悪いからではなく、検証をスキップしたために失敗します。最速のルート:検索需要とフォーラムの証拠で問題が存在することを確認し、競合他社を調査して誰かがすでに稼いでいることを証明し、できるだけ小さなスモークテストを構築し、何かを作る前にコミットメント(預け金、ウェイトリスト登録、意向書)を得る。一人もコミットさせられなければ、アイデアはまだ準備ができていません。 ## Table of contents _2026年6月更新。_ **TL;DR:** ほとんどのビジネスアイデアは、実行が悪いからではなく、検証をスキップしたために失敗します。最速のルート:検索需要とフォーラムの証拠で問題が存在することを確認し、競合他社を調査して誰かがすでに稼いでいることを証明し、できるだけ小さなスモークテストを構築し、何かを作る前にコミットメント(預け金、ウェイトリスト登録、意向書)を得る。一人もコミットさせられなければ、アイデアはまだ準備ができていません。 **[オペレーターの視点]** 私が一緒に働いてきた創業者や自分自身のプロジェクトで、このパターンを何十回も見てきました:アイデアは説得力があり、創業者は情熱的で、実行は堅実 — そしてサイレントなまま立ち上げます。間違ったものを作ったからではなく、6ヶ月費やす前に教えてくれたはずの唯一のステップをスキップしたからです。これが私が使用し、推奨する検証フレームワークです。 ## ほとんどの検証努力が失敗する理由 明らかな失敗モードは、まったく検証しないこと — まず作り、後で質問する。しかし、より微妙な罠は検証の演技です:調査を実施し、友人と話し、漠然とした「素晴らしいアイデア!」という反応を集め、それをシグナルと呼ぶ。 調査は嘘をつきます。人々は礼儀正しい。仮想の文脈で「これに50ドル払いますか?」と聞かれると、答えはほとんど常にイエスです。重要な唯一のシグナルはコミットメントです:実際にお金、時間、または書面による意向書を渡してくれる人。 他のすべてはノイズ低減であり、検証ではありません。 ## ステップ1:問題が実際に大規模に存在することを確認する ソリューションを検証する前に、問題が本物であり、検索されていることを検証してください。 **検索需要は最速のプロキシです。** Googleに問題を入力してください。オートコンプリートの提案、「他の人も質問しています」セクション、そして上位ランキングページを確認してください。結果がなければ、誰も検索していない — そして誰も探していない問題を解決するビジネスは、コンバージョンではなく教育にすべてのエネルギーを費やします。 [Semrush](/recommends/semrush)のようなキーワードツールを使って実際の月間検索ボリュームを確認してください。ターゲット市場で月間1,000〜10,000件の検索がある問題は実行可能です。月間20件の検索しかない問題は、流通の問題を抱えたニッチ製品です。 **フォーラムの証拠は追加の定性的層です。** Reddit、Quora、ニッチなFacebookグループ、Discordコミュニティで問題を検索してください。人々は積極的に不満を言っていますか?解決策を求めていますか?回避策は?本当の不満は宝です — 痛みが人々を公に助けを求めるほど強いことを意味します。 問題を説明している実際の人々のフォーラムスレッドが20件見つからなければ、懐疑的になってください。 ## ステップ2:競合他社を調査する — 既にお金が存在する証拠 よくある創業者の本能:「競合がいないから、私が市場を支配する。」 これはほとんど常に間違いです。競合がないことは通常、市場がないことを意味します。競合は顧客が存在し、支払う意思があることの証拠です。 Googleでソリューションカテゴリを検索してください。誰がランキングしていますか?ランディングページは何を約束していますか?いくら請求していますか?証言やレビューを読んでください — 特にネガティブなものを。ネガティブレビューは製品のロードマップです:市場が求めているが得られていないものを正確に教えてくれます。 本物の製品と本物の顧客を持つ3〜5社の確立した競合が見つかれば、それは健全なサインです。ゼロなら、市場が存在しないと結論づける前にもっと深く掘り下げてください — または赤信号として扱ってください。 **答えるべき重要な質問:** 1. 上位3〜5社はどこですか? 2. いくら請求していますか? 3. レビュアーは何を批判していますか? 4. 私が占領できるポジショニングのギャップはありますか? ## ステップ3:できるだけ小さなスモークテストを作る 問題が存在し、市場にお金があることがわかったら、*あなたの*バージョンがトラクションを得るかどうかテストするために必要な最小限のアーティファクトを作成してください。 これは完全な製品ではありません。シグナルキャプチャメカニズムです。 **オプションA:メールキャプチャ付きランディングページ。** 「ウェイトリストに参加」または「アーリーアクセスを取得」のCTAがある、問題とソリューションを説明する1ページのサイト。コンバージョン率がポジショニングが響くかどうかを教えてくれます。Webflow、Carrd、または公開NotionページのようなツールでOKです — 過剰に複雑にしないでください。 **オプションB:プリセール。** 実際のお金を使ったリアルなチェックアウトフロー。これが最高品質のシグナルです。誰かがまだ存在しないものにお金を渡してくれれば、ソリューションを信じています。返金可能なデポジットでも機能します。 **オプションC:コンシェルジュMVP。** 自動化する前に手動でやってみてください。SaaSではなくコンサルティング。ソフトウェアツールではなくカスタムスプレッドシート。AI生成ではなく手動でキュレートされたニュースレター。一握りの顧客を力ずくで対応し、彼らが何を価値あるものと考えるかを正確に学び、それを中心に製品を作ります。 ## ステップ4:作る前にコミットメントを得る これが本当の検証と願望的思考を分けるゲートです。 スモークテストを実行する前に、アイデアにとって「コミットメント」が何を意味するかを定義してください: - **SaaS / ソフトウェア:** 割引価格でのプリセール、または署名済み意向書 - **コンテンツ / メディア:** 参加するためにクリックしたメール購読者(フォロワーではなく) - **サービス / コンサルティング:** 有料のディスカバリーコールまたは署名済みの提案 - **物理製品:** KickstarterのデポジットまたはPre-order 少なくとも一人がコミットできなければ — 割引でも、返金保証付きでも — アイデアはまだ準備ができていません。これは失敗ではありません。それはシステムが機能しているということです。何ヶ月もの開発時間を節約しました。 ## ステップ5:開始前にパス/フェイルの閾値を設定する 罠はこれです:スモークテストを実行し、ぬるい結果を得て、とにかく進めようと自分を説得する。「ランディングページのコピーが良くなかった。」「十分に宣伝しなかった。」「もう少し時間が必要なだけ。」 停止してください。テストを実行する前に、閾値を書き留めてください: > 「有料広告なしで14日間で50件のウェイトリスト登録が得られたら作ります。50に達しなければ作りません — ポジショニングを変えるか、アイデアをやめるかします。」 書き留めてください。友人に伝えてください。できれば公開してください。そして守ってください。 数字は任意です。重要なのは、事前に決めてデータが冷たく入ってきてもゴールポストを動かさないことです。 ## よくある検証の間違い 1. **購入するかどうか人々に聞く。** 礼儀正しくするためにほとんど常にイエスと言います。重要な唯一の質問:「今すぐ買いますか?」 2. **友人や家族で検証する。** 彼らはあなたを応援しています。あなたの顧客ではありません。 3. **他の人もそれを持っているか確認せずに自分の問題を解決する。** あなたの問題はあなただけに固有かもしれません。フォーラムを確認してください。 4. **調査の回答を検証と呼ぶ。** 調査はアイデアを生み出せます。需要を検証することはできません。お金または本物のコミットメントだけができます。 5. **完全な情報を待つ。** 検証は不確実性を完全に排除することではなく、次のステップに十分なシグナルを得ることです。 ## 「進め」を意味するシグナルとは 以下の組み合わせを探しています: 1. 主要な問題のキーワードで月間1,000件以上の検索ボリューム 2. 競合活動 — 本物のお金を請求している3社以上の実際のプレイヤー 3. 問題への積極的な不満を示すフォーラムまたはコミュニティのスレッドが少なくとも20件 4. ターゲットトラフィックでのスモークテストのコンバージョン率が5%以上 5. 少なくとも一人がコミットする — あなたが懇願することなく、支払い、署名、または預け金をする 5つすべてを達成すれば、実行可能な方向性があります。2〜3つ達成すれば、洗練させる価値のあるシグナルがあります。ゼロなら、根本的に異なるアイデアまたはオーディエンスが必要です。 ## 検証スタック このプロセスで私が使用し、推奨するツール: - **検索需要:** [Semrush](/recommends/semrush) — キーワードボリューム、競合分析、コンテンツギャップを一箇所で - **フォーラムリサーチ:** Reddit、Quora、ニッチなFacebookグループ、Discordコミュニティ - **ランディングページ:** Carrd(無料、高速)またはより多くのデザイン制御のためのWebflow - **メールキャプチャ / ウェイトリスト:** Kit(ConvertKit)で検証しながらリスト構築を開始 - **支払い:** Stripe — 製品を作る前にチェックアウトに直接リンク - **アナリティクス:** スモークテストページのGoogle Analyticsで実際の行動を追跡 ## オペレーターの結論 作れる中で最も高価なものは、誰も欲しがらない製品です。検証はリスクを排除することではありません — それは本番環境でゆっくり失敗するのではなく、紙の上で素早く失敗することです。スモークテストを実行し、コミットメントを得て、開始前に閾値を設定し、結果を尊重してください。シグナルがあれば、わかります。なければ、それもわかります。 --- **関連:** [収益性の高いビジネスの作り方](/how-to-build-profitable-business/) · [成長マーケティング戦略ガイド](/growth-marketing-strategies-guide/) · [起業家になる方法](/how-to-become-an-entrepreneur/) --- ## Claude API のプロンプトキャッシュ:モデルを変えずに入力コストを削減する Source: https://alejandrorioja.com/ja/prompt-caching-cut-your-claude-costs-without-switching-models/ Published: 2026-06-18 Updated: 2026-06-18 Tags: AI Agents, Operations TL;DR: プロンプトキャッシュは、大きく安定した入力 — システムプロンプト、ツール定義、few-shot の例 — のコストを、繰り返しのリクエストでは通常の入力料金のおよそ 10% にまで削減します。その仕組みはプレフィックス一致です。安定したコンテンツの末尾に cache_control マーカーを置き、それより後はすべて可変な内容にします。キャッシュのヒット率を台無しにするミスは、タイムスタンプや UUID がプレフィックスに紛れ込んでしまうことです。 ## Table of contents _2026年6月更新。_ **要点:** プロンプトキャッシュは、大きく安定した入力 — システムプロンプト、ツール定義、few-shot の例 — のコストを、繰り返しのリクエストでは通常の入力料金のおよそ 10% にまで削減します。その仕組みはプレフィックス一致です。安定したコンテンツの末尾に `cache_control` マーカーを置き、それより後はすべて可変な内容にします。キャッシュのヒット率を台無しにするミスは、タイムスタンプや UUID がプレフィックスに紛れ込んでしまうことです。 **[実務者の視点]** 私はコンサルティングのブランドと Pickleland をまたいで 100 を超えるエージェントを運用しています。最大のコスト項目はモデルのティアではありません — 同じ 4,000 トークンのシステムプロンプトを毎回のリクエストでどれだけ繰り返し送っているか、です。プロンプトキャッシュは、モデルにも出力品質にも手を加えることなく、高頻度のエージェントでそのコストをほぼゼロにまで削減してくれました。以下で、その正確な仕組みと、どこに落とし穴があるかを説明します。 ## プロンプトキャッシュが実際に行うこと [Claude](/recommends/claude) API へのすべての呼び出しはトークンを送信します。キャッシュがなければ、リクエスト内のすべてのトークン — システムプロンプト、ツール定義、few-shot の例、そしてユーザーメッセージ — は通常の入力料金で課金されます。キャッシュを使うと、それらのトークンのプレフィックスが最初のリクエストの後に Anthropic のサーバーに保存されます。その同じプレフィックスを共有する後続のリクエストでは、ゼロから再処理する代わりにキャッシュの*読み取り*料金を支払うことになります。 コストの差は本物です: - **キャッシュ書き込み:** ベース入力料金の約 1.25 倍(5 分の TTL)または約 2 倍(1 時間の TTL) - **キャッシュ読み取り:** ベース入力料金の約 0.1 倍 - **損益分岐点:** 5 分の TTL では 2 リクエスト、1 時間の TTL では 3 リクエスト 損益分岐点を超えると — これは 1 日に数回以上動くエージェントなら早々に起こります — それ以降のキャッシュヒットはすべて、それらのトークンに対する約 90% の割引になります。 ## プレフィックス一致の不変条件 これが、他のすべてが従う唯一のルールです: **キャッシュキーは、レンダリングされたプロンプトのプレフィックス一致である**。 Anthropic のサーバーは、プロンプトの先頭から `cache_control` マーカーまでのレンダリングされたコンテンツを保存します。次のリクエストでキャッシュヒットが起こるためには、プロンプトの先頭からそのマーカーまでのすべてのトークンが、バイト単位で同一でなければなりません。 プレフィックス一致のレンダリング順序は: tools → system → messages です。つまり、まず tools 配列がハッシュ化され、次に system ブロック、その後 messages が順番に処理されます。 これが実務で意味するのは: 安定したコンテンツが最初に来なければならない、ということです。システムプロンプトが何か動的なもの — 現在の日付、ユーザー ID、リクエストのトレース ID — を参照していて、それが `cache_control` マーカーより*前*に現れる場合、プレフィックスが変わり続けるため、キャッシュは毎回のリクエストでミスします。 ## キャッシュマーカーをどこに置くか 最もレバレッジの高い対象は次のとおりです: **1. システムプロンプト** システムプロンプトは通常、最も大きな安定ブロックです。詳細なエージェントのペルソナ、振る舞いに関するルールのリスト、出力フォーマットの指示一式 — これらすべては、同じエージェントの呼び出しごとに同一です。マークしましょう: ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic(); const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, system: [ { type: "text", text: `You are a content operations agent for alejandrorioja.com. Your job is to draft blog posts in Alejandro's voice: direct, practitioner, first-person, numbered lists, honest caveats. No hedging. No filler. Every section must earn its place. [... 2000 more tokens of stable instructions ...]`, cache_control: { type: "ephemeral" }, }, ], messages: [ { role: "user", content: "Draft a post about prompt caching.", }, ], }); ``` system ブロックの `cache_control: { type: "ephemeral" }` は、そのブロックまで(それを含む)すべてをキャッシュするよう Claude に指示します。`messages` 配列は可変 — リクエストごとに異なる — であり、キャッシュ境界の外側にとどまります。 **2. ツール定義** エージェントがツールを使う場合、それらの定義は相当な量になり得ます。description、パラメータ名、enum 値を備えた、よく文書化されたツールスキーマは、1 ツールあたり 500〜1,000 トークンに達することがあります。5 つのツールがあれば、毎回の呼び出しで再処理のために支払うトークンは最大 5,000 トークンになります: ```typescript const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, tools: [ { name: "search_airtable", description: "Search the Airtable content queue...", input_schema: { type: "object", properties: { query: { type: "string" } } }, }, // ... more tools ... { name: "post_to_kit", description: "Schedule a broadcast via the Kit API...", input_schema: { /* ... */ }, // Mark the last tool to cache the entire tools array } as Anthropic.Tool & { cache_control: { type: "ephemeral" } }, ], system: "...", messages: [...], }); ``` 配列の*最後*のツールをマークします。プレフィックス一致は、その地点から tools 配列全体をカバーします。 **3. messages 内の few-shot の例** `messages` 配列の前方のメッセージとして静的な few-shot の例を渡す場合、それらもキャッシュできます。最初の N 個のメッセージとして構成し、最後の例のターンをマークします: ```typescript const messages: Anthropic.MessageParam[] = [ { role: "user", content: [ { type: "text", text: "Here are examples of posts in my voice:\n\n[Example 1...]\n\n[Example 2...]", cache_control: { type: "ephemeral" }, } as Anthropic.TextBlockParam & { cache_control: { type: "ephemeral" } }, ], }, { role: "assistant", content: "Understood. I'll follow that voice.", }, // The actual user turn follows — this is volatile, no cache marker { role: "user", content: actualUserRequest, }, ]; ``` ## キャッシュしてはいけないもの(サイレントな無効化要因) これらは安定しているように見えて、そうではないものです — そしてあなたのヒット率を静かに台無しにします。API は警告してくれません。毎回のリクエストで `cache_creation_input_tokens` が表示され、なぜなのかと首をかしげることになるだけです。 **システムプロンプト内のタイムスタンプ。** 最もよくある単一のミスです: ```typescript // This invalidates the cache on every request const system = `You are an agent. Current time: ${new Date().toISOString()}`; ``` タイムスタンプは、それがふさわしい場所であるユーザーメッセージへ移しましょう: ```typescript // Stable system prompt — cacheable const system = `You are an agent. Use the current time provided by the user.`; // Volatile user message — not cached const userMessage = `Current time: ${new Date().toISOString()}. Run the daily brief.`; ``` **ランダムな UUID とトレース ID。** 同じ問題です。ログ記録のために system ブロックにトレース ID を注入すると、毎回のリクエストで新しいプレフィックスになります。 **非決定的な JSON シリアライズ。** オブジェクトをシステムプロンプトにシリアライズする際にキーの順序が保証されていないと、元になるデータが同じでも、レンダリングされた文字列が異なることがあります。安定したキー順序でシリアライズするか、テンプレート文字列を使いましょう。 **動的な few-shot の選択。** 現在のクエリに基づいて few-shot の例を選び、それをキャッシュされるプレフィックスに入れているなら、「安定した」プレフィックスをクエリ依存にしてしまっています。キャッシュ層には固定の例を使うと決めるか、動的な例をキャッシュされないメッセージのターンへ移しましょう。 ## キャッシュのヒット率を検証する すべてのレスポンスには使用量のメタデータが含まれます。確認しましょう: ```typescript const response = await client.messages.create({ /* ... */ }); console.log({ inputTokens: response.usage.input_tokens, cacheRead: response.usage.cache_read_input_tokens, cacheWrite: response.usage.cache_creation_input_tokens, outputTokens: response.usage.output_tokens, }); ``` 最初のリクエストでは: `cache_creation_input_tokens` がゼロでない値になり、`cache_read_input_tokens` は 0 になります。これが書き込みです。 キャッシュヒットでは: `cache_read_input_tokens` がゼロでない値になり、`cache_creation_input_tokens` は 0 になります。これが読み取りです。 毎回のリクエストで `cache_creation_input_tokens` が見えているなら、プレフィックスが変化しています。各呼び出しの前に、レンダリングされたシステムプロンプトの最初の 200 文字を出力するログ文を追加しましょう — 浮動するタイムスタンプがあれば、すぐに目に飛び込んでくるはずです。 ## 1 時間の TTL:追加の書き込みコストに見合うとき デフォルトの TTL は 5 分です。エージェントが低頻度で動く場合 — 5 分に 1 回未満 — 読み取りを得られないまま、ほとんどのリクエストでキャッシュ書き込みコストを支払うことになります。 ```typescript // Opt into a 1-hour TTL cache_control: { type: "ephemeral", ttl: "1h" } ``` 1 時間の書き込みコストは、1.25 倍ではなくベース入力料金の約 2 倍です。計算はこうです: 1 時間に 3 回以上キャッシュにヒットしているなら、1 時間の TTL は節約になります。エージェントが 1 日に 1 回しか動かないなら(私のデイリーブリーフのように)、1 時間の TTL でも助けにはなりません — 毎回書き込みコストを支払うことになります。その場合、システムプロンプトが膨大でない限り、キャッシュの恩恵はわずかです。 私のデイリーブリーフのエージェントは 3,000 トークンのシステムプロンプトを持ちますが、1 日に 1 回しか動きません。キャッシュは役に立ちません。私のニュースレターのエージェントは、ドラフト作成中に 1 セッションあたり何十回も動きます — キャッシュは大幅に節約してくれます。 ## 事前ウォーミング:最初のリクエストを安くする 来ることが分かっているトラフィックの急増 — バッチジョブ、API のローンチ — があるなら、低コストのダミーリクエストでキャッシュを事前にウォーミングできます: ```typescript // Pre-warm: write the cache at near-zero output cost await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1, // minimal output system: [{ type: "text", text: stableSystemPrompt, cache_control: { type: "ephemeral" } }], messages: [{ role: "user", content: "ping" }], }); // Now the real requests read from cache ``` これが主に役立つのは、多数の並列リクエストを立ち上げていて、それぞれがキャッシュの書き込みを競い合うのではなく、温まったキャッシュにヒットしてほしいバッチ処理の場合です。 ## エージェント型ループにおけるプロンプトキャッシュ マルチターンのエージェント型ループでは、会話の履歴がターンごとに増えていきます。キャッシュはこれをうまく扱えるほど賢くできています: 20 ブロックの遡及ウィンドウを使い、直近 20 個のコンテンツブロックの中で最も長く一致するプレフィックスを見つけます。 実務上の含意は: 安定したコンテンツ(システムプロンプト、ツール定義)を一番上に固定しておく、ということです。messages 配列の末尾で増えていく会話履歴は、安定ブロックのプレフィックス一致を壊しません — それらは可変なコンテンツより前にあり、プレフィックス一致は一番上から始まるからです。 実際、私のエージェントはターンを次のように構成しています: ``` System (cached) → Tools (cached) → Few-shot (cached) → Turn 1 → Turn 2 → ... → Current turn ``` キャッシュは few-shot のマーカーまでのすべてをカバーします。その後で増えていくターンの履歴は毎回再処理されますが、それで構いません — それらのトークンはセッション固有であり、安定したプレフィックスに比べれば小さいからです。 ## 請求書での見え方 高頻度のエージェントを例に取りましょう: 1 日 100 回の呼び出し、4,000 トークンのシステムプロンプト、Sonnet の料金。 キャッシュなし: - 100 × 4,000 トークン × $3/1M = **1 日 $1.20** キャッシュあり(5 分の TTL、ピーク時に 50 回/時と仮定): - 5 分ごとに 1 回の書き込み × $3.75/1M × 4,000 トークン = 書き込みで 1 日 約 $0.02 - 1 日 約 98 回の読み取り × $0.30/1M × 4,000 トークン = **読み取りで 1 日 $0.12** これは、それらの入力トークンに対しておよそ 90% の削減です。規模が大きくなると — 1 日 1,000 回の呼び出し — 差はさらに積み重なります。そしてこれは、[Haiku 対 Sonnet の計算](/ai-agent-cost-math-when-haiku-beats-sonnet)によるモデルルーティングの節約に上乗せされるものです: キャッシュはどのティアでも機能します。 ## 実務者としての結論 プロンプトキャッシュは Claude API において最も簡単なコスト最適化です: すでに書いているコンテンツブロックに 1 つフィールドを追加するだけです。制約はプレフィックスの安定性に対する規律です — キャッシュマーカーより前に動的なものを置かないこと。システムプロンプト、ツール、そして静的な例を可変なコンテンツから解放しておけるなら、キャッシュヒットごとに通常の入力コストの約 10% を支払うだけで済みます。大きく安定したプロンプトを持つ高頻度のエージェントにとって、これはモデルのティアを切り替えるよりも大きなレバーです。 --- **関連記事:** [AI エージェントのコスト計算:Haiku が Sonnet に勝つとき](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [イベント駆動型 対 スケジュール型のエージェント](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [ビジネスを回すために私が実際に使っている 5 つの AI ツール](/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/) --- ## 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` で再試行し、クレジット方式の再課金が適用される。エージェントを無人で動かしているなら、単一の誤検知による拒否が実行全体を行き止まりにしないように、これを組み込んでおこう。これは私が[本番で失敗し続ける](/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年のオペレータースタック](/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分のパスで始めるには十分ですし、自分でエージェントを作りたくなければ[mentioned.at](https://mentioned.at)のような専用チェッカーを使ってもいいでしょう。方法論は私の[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-23 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-23 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-24 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-25 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-21 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-25 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: