1. Claude Opus 4.8は4.7の正常進化。料金は$5/$25のまま据え置き。Fast modeが前世代比3倍安く、バグ見逃しは4.7の約1/4に。新しいeffort制御で「速さとコスト」を自分で握れるようになった。

新しいモデルが出るたびに気になるのは「で、副業の財布にいくら響くの？」だと思う。結論から言うと、Claude Opus 4.8は値上げなしの性能アップ。2026年5月28日にAnthropicが公開し、API料金は$5/$25（入力/出力・100万トークンあたり）で4.7から据え置きのまま、ベンチマークと正確さが上がった。SE歴20年でClaude Code Max枠を毎日回している筆者の視点で、副業・フリーランスに効くポイントだけ抜き出して整理する。

ムラサキ

正直、新モデル＝値上げを身構えてたんですが、今回は据え置き。日々トークンを溶かしている側としては、これだけで十分ありがたいニュースです。

Claude Opus 4.8とは？Opus 4.7から何が変わったか

Opus 4.8は、ゼロから作り直した新世代ではなく、4.7を土台にした品質向上版という位置づけ。Anthropicの発表記事「Introducing Claude Opus 4.8」でも、コーディング・エージェント・推論・実務タスクのベンチマーク全般で4.7を上回ったと説明している。前提として、Opus 4.7時点の副業での立ち位置はOpus 4.7発表時の使い分け基準に整理済みなので、4.7を触っていた人はそこからの差分で読むと早い。

主な改善点：価格据え置きで性能・正確さが向上

押さえるべき変更は3つだけ。料金が$5/$25で据え置き、Fast modeが前世代比3倍安く、そして「コードの欠陥を見逃さず指摘する」正確さが4.7の約4倍に上がった。Anthropicは後者を「honesty（誠実さ）」の改善と表現していて、根拠の薄いまま『できました』と言い切る傾向が減ったとしている。

加えてデフォルトの思考量（effort）がxhighからhighへ下がった。これは性能ダウンではない。公式によると、4.8のhighはコーディングで4.7のデフォルトとほぼ同じトークン量で、スコアはむしろ上というチューニングが効いている。同じ働きをより少ない手数で、というのが今回の地味だが効く進化。

ベンチマークで見るOpus 4.8の実力（GPT-5.5との比較）

GPT-5.5との比較で見ると、Opus 4.8は得意・不得意がはっきり分かれる。発表記事とSystem Cardの数値を主要軸だけ並べると、こうなる。

ブラウザ・PC操作と知識労働ではGPT-5.5を上回る一方、コマンドライン主体のTerminal-Bench 2.1ではGPT-5.5に一歩譲る。ここは隠さず書いておきたい正直な弱点。なお各ベンチは評価ハーネスの違いで数値が動くので、厳密な検証はClaude Opus 4.8 System Cardで確認するのが確実。副業用途なら、ターミナル一発勝負よりもエージェント的に手順を回す場面が多いはずで、その意味では4.8の伸びは噛み合っている。

副業・フリーランスがOpus 4.8で得られる3つのメリット

数字に落とすと、副業規模でも効く変化が見えてくる。

追加コストゼロのアップグレード：/は変わらない

フロンティアモデルの更新で値上げしないのは、AI業界ではむしろ珍しい。Opus 4.8の通常料金は入力$5・出力$25（100万トークンあたり）で、4.7とまったく同じ。すでにOpusのコストで回している人は、財布の前提を変えずに性能だけ受け取れる。乗り換え判断で「値上げ分が見合うか」を計算しなくていい–この時間の節約こそ、地味だが大きい。

Fast modeが3倍安く：APIコスト削減の具体計算

Fast modeは「速度のための上乗せ料金」で、Opus 4.8では入力$10・出力$50。標準の2倍だが、前世代のFast（Opus 4.6時代は$30/$150）と比べると、ちょうど3分の1に下がった。

副業規模で試算してみる。1回あたり入力20万＋出力10万トークンの処理を、月100回回す前提だと、こうなる（公式料金からの筆者試算）。

• 標準（Fast不使用）：1回 約$3.5 → 月 約$350
• 新Fast（4.8）：1回 約$7 → 月 約$700
• 旧Fast（前世代）：1回 約$21 → 月 約$2,100

ここで早とちりしないでほしい。速度が要らないなら標準が最安。Fastの値打ちは、待ち時間が成果に直結する処理を「現実的なコストで速くできる」点にある。前世代だと月2,100ドル相当で手が出なかったFast運用が、700ドル前後まで降りてきた。対話的なセッションや、レビューを何往復もする作業でこそ効く。

バグ見逃しが4倍少ない：コーディング副業での実用価値

副業でコードを書く人に一番効くのが、この正確さの改善。Anthropicの評価では、Opus 4.8は自分が書いたコードの欠陥を見逃さず指摘する確率が4.7の約4倍に上がった。AIが『動きます』と言ったコードが実は壊れていた、というあの手戻りが減る方向の変化だ。レビュー工数を外注している感覚の個人開発者にとって、これは単価以上の価値になりうる。

実際にAIごとのバグ検出力がどれだけ違うかは、実バグ6本でのレビュー精度の差を測った検証で具体的な差が出ている。モデル選びの判断材料として合わせて見ると、4.8の伸びの意味がつかみやすい。

新機能「effort制御」を副業ワークフローに組み込む

今回の隠れた主役は、モデルそのものより「effort制御」かもしれない。

effortレベル別の使い分けガイド（low/medium/high/extra/max）

effortは、Claudeがどれだけ深く考えるかを自分で回せるダイヤル。公式ドキュメント「Effort（Claude API Docs）」によると、レベルはlow・medium・high（既定）・extra・maxの5段階。highより上は思考頻度と深さが増し、下げるとレスポンスが速くなりレート消費も穏やかになる。Claude Codeでは extra が「xhigh」という名前で出てくる点だけ覚えておけばいい。

この制御は、月額のClaude Proから最上位のMaxまで全プランで使え、追加料金もかからない。claude.aiとCoworkではモデルセレクタの隣に並ぶので、画面からそのまま切り替えられる。

API側でも同じ発想で指定する。

# Messages API で effort を指定するイメージ
message = client.messages.create(
    model="claude-opus-4-8",
    effort="high",   # low / medium / high(既定) / extra / max
    max_tokens=64000,
    messages=[...],
)

extra や max を使うときは、思考に必要なトークン余地を確保するため max_tokens を大きめ（公式の目安は64,000から調整）に取るのがコツ。

週末起業家が毎日使うタスク別のeffort設定例

「全部highでいい」と思いがちだけど、副業のタスクは難易度がバラバラ。手元の作業を雑に振り分けると、こんな具合になる（筆者の運用方針）。

ポイントは「難所だけ上げる」。Claude Codeはeffortを上げた分のトークン増を見込んでレート上限が引き上げられているので、難しいタスクで遠慮なくextraを使い、軽い作業はlowに落として温存する–このメリハリが、月末のレート切れを防ぐ一番効く運用になる。

ムラサキ

個人的に一番うれしいのが、軽い作業をlowに落とせること。SNS文の量産でレートを食いつぶす、みたいな事故が減りそうです。

SonnetとOpus 4.8、どちらを使うべきか？

「とりあえずOpus」を卒業すると、コストはぐっと締まる。

コスト比較：Opus vs Sonnetの価格差と費用対効果

料金はSonnet 4.6が$3/$15、Opus 4.8が$5/$25。入力で1.67倍、出力で1.67倍の差だ。ブログ自動化のような月間ワークロード（入力500万＋出力200万トークン）で並べると、Sonnetが月$45、Opusが月$75で、差は月$30前後（筆者試算）。

この差を「Opus一択」で毎回払う必要はない。日常の実装や定型処理はSonnetで回し、設計や難所だけOpusに投げる–この発想を具体化したのがOpus・Sonnet・Haikuでコストを半減する3層の組み方で、モデル単価の差をそのまま月額の差に直結させない設計の実例として読める。

副業タスク別の使い分け判断フロー

迷ったときの分岐はシンプルにできる。

graph TD
  A["タスクを確認"] --> B{"難所・設計判断あり?"}
  B -->|"はい"| C["Opus 4.8"]
  B -->|"いいえ"| D{"長文脈の横断理解?"}
  D -->|"はい"| C
  D -->|"いいえ"| E["Sonnet 4.6"]
  C --> F{"待ち時間が重要?"}
  F -->|"はい"| G["Fast mode併用"]
  F -->|"いいえ"| H["標準で実行"]
  classDef opus fill:#dde8f5,stroke:#9bb4d4;
  classDef sonnet fill:#e3f0e3,stroke:#a9cba9;
  class C,G,H opus;
  class E sonnet;

設計判断や長文脈の横断理解が要るならOpus 4.8、そうでなければSonnet 4.6。Opusに振った中でも、待ち時間が成果に効くならFastを足す。この3問だけで、コストと品質のバランスはだいたい収まる。

注意点：Opus 4.8で変わらないこと・制限事項

良い話ばかりではない。先に知っておくと損しない2点。

Dynamic WorkflowsはClaude Code Enterprise/Team/Maxで利用可

同時公開された「Dynamic Workflows」は、Claude Codeが数百の並列サブエージェントを走らせ、出力を検証してから報告する大規模タスク向けの機能（研究プレビュー、Claude Code v2.1.154以降）。利用は全有料プランが対象で、Max・Teamは既定でオン、ProとEnterpriseは有効化が必要（Proは/config、Enterpriseは管理者設定）。実際に副業で走らせた手触りは別記事にまとめる予定。

高effort設定でのトークン消費量に注意

effortは便利だが、上げれば上げるほどトークンを食う。extraやmaxは思考も手数も増えるぶん、同じタスクでも消費が膨らむ。Claude Code側はレート上限が引き上げられているとはいえ、APIで従量課金している場合は青天井になりうる。「難所だけ上げる」を徹底し、走らせっぱなしの自動化ではmaxを安易に常用しないのが安全。Opusのトークナイザは入力に対して生成トークンが増えやすい特性もあるので、移行前に自分のワークロードで概算しておくと事故が減る。

よくある質問

まとめ

Opus 4.8は派手な新世代ではなく、副業の現場にじわっと効くアップデートだった。要点は3つ。

1. 料金は$5/$25で据え置き。値上げ分の計算なしに性能だけ受け取れる。
2. Fast modeが前世代比3倍安く、バグ見逃しは4.7の約1/4。速さと正確さの両方が現実的なコストに降りてきた。
3. effort制御で「難所だけ深く、軽作業は速く」を自分で握れる。Sonnetとの使い分けと合わせれば、月のAIコストはまだ削れる。

まずは普段のタスクをlow/high/extraにざっくり振り分けて、1週間レート消費を眺めてみるところから。自分のワークロードの「どこにコストが乗っているか」が見えると、Opus 4.8の据え置き料金とeffort制御は一気に武器になる。

ムラサキ

据え置きでこの伸び幅なら、乗り換えで悩む理由はほぼなし。あとは自分の作業をどうeffortに割り振るか、ですね。

1. ChatGPT・Claude・Geminiの企業向けプランをシステム開発業務の観点で9軸比較。
2. 料金構造・コーディング支援・チーム情報共有の3軸が選定の決め手になる。
3. エンタープライズではAPI利用の扱いも3社で構造が違うため、個人プランの感覚で選ぶと外す。

会社で生成AIを業務利用する場合、「個人プランで触ってきた感覚」がそのまま企業導入の判断材料にならない。料金モデルが違う、データガバナンスの前提が違う、コーディング支援の含まれ方が違う。同じ「Enterpriseプラン」と書かれていても、3社で構造が大きく違う。

この記事はSE業務向けに、ChatGPT・Claude・Geminiの企業向けプランを9軸で比較する検討メモだ。社内のガイドライン整備を提案する立場で、ツール選定の論点を整理する目的で書いた。会社でガイドライン策定前に決めるべき5論点を整理した次のフェーズで、具体的にどのプランを推奨するかを判断する材料になる。

ムラサキ

SE歴20年・現役SEマネージャーの筆者の前提を最初に開示する。会社はGoogle Workspaceを使っており、Geminiは実際に業務で触っている。Claudeは個人でPro→Max 5xを使い、Claude Codeを日常運用中。ChatGPTは個人フリープランのチャット利用と、コードレビューでのCodex経験のみ。エンタープライズ各プランは社内で公開・利用されておらず、未経験。記事は公開情報ベースの検討メモであり、エンタープライズ実装の体験談ではない点を最初に明示する。

なぜSE業務でエンタープライズAIの選定が難しいのか

個人プランの体感がそのまま企業導入の判断にならない理由

ChatGPT Plus・Claude Pro・Gemini AI Proを個人で触っていれば、AIモデルの性格やクセは把握できる。ただ、企業導入のときに見るべきポイントは別レイヤーにある。誰がいくら払うか（料金構造）、データはどう守られるか（ガバナンス）、何人で使えるか（管理機能）、チーム開発でどう共有するか（情報共有）。これらは個人プランでは見えない論点だ。

システム開発業務特有の評価軸が抜けがちな点

一般的なエンタープライズAI比較記事は、議事録要約や営業文書ドラフトのような汎用業務を前提にしていることが多い。SE業務に特化すると、コーディングエージェント（CLI／IDE拡張）、ローカルコードベース理解、プロジェクト文脈定義ファイル（CLAUDE.md / GEMINI.md / AGENTS.md相当）、設計→実装→テストの段階的タスクへの適性、といった軸が前面に出る。

本記事の比較方針（公開情報ベースの検討メモ）

筆者のエンタープライズ実利用経験はゼロのため、本記事は各社の公式ドキュメント（Anthropic Support、OpenAI Pricing、Google Cloud / Workspace Help）と公開記事をソースに構成した。料金・機能の最新値は変動するので、最終判断時は各社公式ページでの再確認を必須にしてほしい。

なお本記事では「シート」を「ユーザー1人分のライセンス」を指す業界用語として使う。「20シート契約」は「20ユーザー分のライセンス契約」と同義だ。

3サービスのエンタープライズ位置づけを整理する

3社それぞれ、企業向けプランの構造が違う。まず全体像を押さえる。

ChatGPT Business / Enterprise の構成

ChatGPT Business（$25/seat/月、年契約）は2人以上から契約可能で、Codex・SSO非対応・データの学習利用なしがデフォルト。ChatGPT Enterpriseは150シート以上を最低条件にした上位プランで、SSO/SAML・SCIM・監査ログ・カスタムデータ保持・EKM・コンプライアンスAPIを揃える。Enterprise契約にはAPI access（バンドルクレジット or 交渉割引）が含まれるケースが多い。

Claude Team / Enterprise の構成

Claude Teamは5シートから契約可能で、Standard（$25/seat/月）とPremium（$125/seat/月）の2層構成。Premiumに含まれるClaude CodeとCowork（デスクトップ作業エージェント）が、開発業務向けの中核機能だ。

Claude Enterpriseは20シートから契約可能で、現行モデルは「シート料金（$20/seat/月〜）＋全使用API従量課金」のUsage-basedプラン。チャット・Claude Code・Cowork含めて、使った分だけAPI料金が別請求される。500Kコンテキストウィンドウ、HIPAA Readiness、Compliance APIが揃う。

Gemini｜Workspace付帯AIとCode Assistは別契約（混同注意）

ここが最も誤解されやすいポイントだ。Google Workspaceで使っているGeminiと、Gemini CLI / Code Assistは別契約系統の製品になる。

graph TD
  A["Google Workspace契約"] --> B["Workspaceアプリ内GeminiGmail・Docs・Sheets等"]
  A --> C["Geminiアプリgemini.google.com"]
  D["Gemini for Google Cloud契約"] --> E["Gemini Code AssistStandard / Enterprise"]
  E --> F["Gemini CLI"]
  E --> G["VS Code/IntelliJ拡張エージェントモード"]
  style A fill:#e8f4f8,stroke:#6699aa
  style D fill:#fff4e6,stroke:#cc9966

2025年1月以降、Gemini for Google Workspaceアドオンの単体販売は終了し、Business Plus / Enterpriseプランの標準機能に組み込まれた。これに含まれるのはWorkspaceアプリ内のAI機能とGeminiアプリのチャット利用。Gemini CLIとCode Assistは含まれない。Code Assistを使うには、Standard $19/seat/月 または Enterprise $45/seat/月の別ライセンス契約が必要になる。

社内のライセンス割当状況は、Google Admin コンソール → ユーザー → ライセンスタブで「Gemini Code Assist Standard」表示の有無を確認すれば分かる。

料金構造の違い｜固定費型・従量型・ハイブリッド型

ChatGPT：固定シート＋API別請求（ハイブリッド型）

Business・Enterpriseとも基本はシート単価×人数の固定費。API利用は基本的に別請求で、Enterpriseでは契約交渉でバンドルクレジットや割引が組み込まれることが多い。Codex CLI / IDE拡張の利用はChatGPT本体プランに含まれており、API課金とは別系統。シート単価が固定なので、月次の支出が予測しやすい。

Claude Enterprise：シート＋全使用従量（フル従量寄り）

Claude Enterpriseは構造が独特で、シート料金（$20/seat/月〜）はアクセス権のみ、チャット・Claude Code・Coworkの全使用がAPI標準料金で別請求される。シートに含まれる利用枠はゼロ。ヘビーユーザーが多い組織では支出が膨らみやすいが、逆に「使う人と使わない人の差」を予算管理しやすいメリットがある。

Claude Teamの場合はStandardかPremiumかで構造が変わる。Premium（$125/seat）はClaude Code込みでセット価格になっており、Enterpriseに比べると個人のClaude Pro/Maxプランの延長線で考えやすい。

Gemini Code Assist：シート内に開発支援込み（固定費寄り）

Code Assist Standard $19 / Enterprise $45 のシート料金に、Code Assist本体と Gemini CLI の利用枠が含まれる。割当枠を超えるとレート制限がかかる構造で、API利用とは分離されている。Vertex AI経由のAPI利用は別請求になる。固定費でコスト見通しがつきやすい点が特徴だ。

同じ「Enterpriseプラン」でも構造が違うことの意味

3社の料金モデルは、同じ「企業向けプラン」でも前提が大きく違う。比較すると次のような違いが見える。

Claudeのモデルは「シートが安い分、使うほど課金される」設計で、Geminiは「シートにあらかじめ込みで、上限がレート制限」、ChatGPTは「シート＋API別請求のハイブリッド」と整理できる。

データガバナンスと管理機能の比較

学習利用デフォルトとオプトアウトの扱い

3社とも、企業向けプランでは「入力データがモデルの学習に使われない」がデフォルト設定になっている。個人プラン（ChatGPT Plus、Claude Pro、Gemini個人）はオプトアウト可能だが、デフォルトの扱いは各社で異なる。

Geminiについては注意点があり、認証方式によってデータ保護の条件が変わる。Code Assist有償ライセンス・Vertex AI・AI Studio有償版で認証している場合は保護対象だが、それ以外（Workspaceアカウントのみでの認証含む）は入出力データがGoogleに再利用される可能性がある、と公式に記載されている。

SSO/SAML・SCIM・監査ログ・データ保持

主要な管理機能の比較を整理する。用語が多いので、前提を1段落でまとめる。

SSO/SAMLは社内IdP（Microsoft Entra ID・Okta等）でAI製品にログインする仕組み。SCIM自動プロビジョニングは、人事システムでアカウント登録・退職処理をすると、AI製品側のアカウントも自動で作成・無効化される仕組みで、100人を超える組織では実質必須機能だ。EKM（Enterprise Key Management）はデータ暗号化キーを企業側のAWS KMS / GCP KMSなどで管理する仕組みで、キーを取り消せばサービス提供者側もデータを読めなくできる。HIPAA Readyは米国の医療情報保護法の技術要件を満たした状態で、日本の医療系・国際展開企業向けの認証指標になる。

スペンドリミットと利用量モニタリング

Claude Enterpriseは管理者が組織レベル・個人レベルで支出上限を設定できる。Gemini Code Assistは固定費＋レート制限のため、突発的なコスト爆発のリスクが構造的に低い。ChatGPT Enterpriseは利用量分析機能を持つが、API分は別系統のため両方を見る必要がある。

コーディング支援｜CLIエージェント3者の現在地

ここがSE業務向け選定の中核だ。3社ともCLIで動くコーディングエージェントを揃えており、現在は機能の概要レベルではほぼ横並びになってきている。

ChatGPT｜Codex CLI / Codex IDE拡張

OpenAIのCodexはChatGPT Plus・Pro・Business・Edu・Enterpriseの各プランに含まれる。CLIとIDE拡張の両方を提供し、GPT-5系モデルで動作。コードレビュー・小規模スクリプト生成・関数単位のリファクタリングで実用レベル。筆者のCodexコードレビュー利用経験では、PR単位のレビュー指摘の質は高い。

Claude｜Claude Code（CLI＋IDE拡張）

Claude Pro・Max・Team Premium・Enterpriseの各プランに含まれる。CLIとVS Code / JetBrains拡張を提供。Sonnet 4.6・Opus 4.7・Haiku 4.5の3モデルを使い分けでき、CLAUDE.md でプロジェクト文脈を定義する設計。コミュニティ蓄積とノウハウ量が現時点では他2社より厚い。筆者がMax 5xで日常運用中で、Opus・Sonnet・Haikuの使い分けでコスト管理しやすい。

2026年5月にはClaude Codeへ大規模タスク向けの「Dynamic Workflows」（研究プレビュー）が追加され、Enterprise・Team・Maxプランで利用できる。プラン選定時はこの対象範囲も判断材料になる。

Gemini｜Gemini CLI / Code Assist エージェントモード

Gemini CLIは2025年6月リリースのオープンソースAIエージェント。Code Assist Standard / Enterpriseライセンスと組み合わせて法人利用する。GEMINI.md でプロジェクト文脈を定義（CLAUDE.mdと同じ思想）。VS Code / IntelliJの「Gemini Code Assist エージェントモード」がGemini CLIを基盤に動く。Code Assist Enterpriseでは100万トークンのコンテキストウィンドウとプライベートコードベースに基づくカスタマイズが利用可能。

MCPサポートとプロジェクト文脈定義ファイル

3者ともMCP（Model Context Protocol）に対応し、プロジェクト文脈定義ファイルの設計思想を持つ。MCPは2024年にAnthropicが提唱した規格で、その後3社が採用したことで、外部ツールとの連携プロトコルが事実上の業界標準になりつつある。

設計・実装を段階的に進めるタスクへの適性

ここで言う「設計・実装を段階的に進めるタスク」とは、ローカルにある既存コード・設計書・要件メモを参照しながら、要件整理→設計→実装→テストへと積み上げていく開発スタイルを指す。AIが一度きりの応答ではなく、プロジェクト全体の文脈を持ち続けて開発を進められるかが評価軸になる。

コンテキストウィンドウとコードベース横断理解

各社のコンテキストウィンドウは次の通り。

実用上、200K〜1Mのレンジに大きな機能差はない。重要なのは「コンテキスト窓の数字」よりも、ファイルを横断して読み込む実装機能だ。Claude Codeは .claude/ 配下の設定・サブエージェント機能・/compact でのコンテキスト管理が成熟しており、Gemini CLIは GEMINI.md でルール定義しMCP経由で外部システム連携、Codexは AGENTS.md ベースの実装になっている。

設計・実装を段階的に進めるタスクとの相性

筆者のClaude Code個人開発実体験では、CLAUDE.md と BUGS.md を仕様書・課題管理として使う運用が実用レベル。プロジェクト文脈をファイルに固定することで、セッションをまたいでもAIが文脈を保持する。Gemini CLI も GEMINI.md で同じ運用ができる構造で、Codexは AGENTS.md で対応する。

実体験ベースで比較できるのはClaude Codeだけで、Gemini CLIとCodexの段階的タスク適性についての断定的な評価は控える。公開情報ベースでは3者とも同等水準の設計になっている。

3サービスの実装機能差を比較

API利用の扱い｜エンタープライズで何が変わるか

個人プランの感覚をそのままエンタープライズに持ち込むと外しやすいのが、このAPI利用の扱いだ。

ChatGPT Enterprise：API利用は契約に含まれる（バンドル/割引）

Enterprise契約にはAPI accessが含まれることが標準で、バンドルクレジットや割引レートが契約交渉で組み込まれる。シート料金とは別建てだが、同じ契約内で管理される。Business以下のプランではAPIは完全に別アカウント・別請求になる。

Claude Enterprise：シート料金とAPI料金が完全分離

Claude Enterpriseの現行モデルでは、シート料金は「プラットフォームへのアクセス権のみ」を表す。チャット・Claude Code・Coworkの全使用はAPI標準料金で別途従量課金される。シートに含まれる利用枠はゼロで、毎月の支出は実利用量に完全比例する。一方で、Anthropic API ConsoleのAPIキー利用は従来通り別契約として残る。

Gemini Code Assist：シート料金に開発支援API分が含まれる

Code Assist StandardとEnterpriseのシート料金には、Code Assist本体と Gemini CLI の利用枠が含まれる。割当枠の範囲内で使う限り追加課金は発生せず、超えるとレート制限がかかる。Vertex AI 経由でGemini APIを叩く場合は、Cloud Billingで別途請求される。

API利用時のデータ保護｜3社ともデフォルトで学習利用なし

API利用時のデータ保護については、3社とも標準API契約の時点で「入力データは学習に使われない」がデフォルトになっている。エンタープライズ契約で追加されるのは、データ保持期間のカスタマイズ・データ所在地の指定・EKM/CMEK連携・監査ログのエクスポート等で、学習利用の扱い自体は標準APIから強化されるわけではない。

ただしGeminiは認証方式で扱いが変わる。Vertex AI経由・AI Studio有償版・Code Assist有償ライセンス経由のAPI利用は学習対象外だが、AI Studio無料版では学習に使われる可能性がある点に注意したい。

個人プランの感覚をそのままエンタープライズに持ち込むと外す

3社のエンタープライズAPI扱いをまとめると次のようになる。

graph LR
  A["シート料金"] --> B["ChatGPT EnterpriseAPI利用含むバンドル/割引"]
  A --> C["Claude Enterpriseシート＝アクセス権のみ使用は全てAPI従量"]
  A --> D["Gemini Code Assistシートに開発支援込みVertex API別請求"]
  style B fill:#e8f4f8,stroke:#6699aa
  style C fill:#ffe8e8,stroke:#cc6666
  style D fill:#fff4e6,stroke:#cc9966

個人ProプランはClaude Code利用込みで$20、API課金は別アカウントという感覚で使えるが、Enterpriseはこの感覚が通用しない。特にClaudeは「シート料金が安いから安心」と思って契約すると、API従量で月次予算を大きく超える可能性がある。

組織・チーム内の情報共有とコラボレーション機能

ここが筆者として最も気になっている評価軸だ。Claude Codeを一人で使っている立場からすると、チーム開発でAIをどう共有するかは未踏領域に近い。

セッションの引き継ぎ・並行作業の可否

「自分が進めていたAIセッションを途中から別の人が引き継げるか」「複数人で同時並行に同じプロジェクトに対してAIを動かせるか」は、チーム開発でAIを共有するときの基本機能だ。

3社とも「共有プロジェクト」「ワークスペース」の概念は持つが、個人セッションを他者にそのまま引き継ぐ機能は提供されていない。実態としては「プロジェクト単位で文脈を共有し、各自が新セッションを開く」運用になる。

プロジェクト状態のエクスポート・チーム共有

セッション履歴のエクスポート機能は限定的だ。実用的には、プロジェクト文脈定義ファイル（CLAUDE.md / GEMINI.md / AGENTS.md）をGit管理することで、文脈の引き継ぎを実現するのが現状の主流パターンになる。

これはAI製品の機能というより、運用側で工夫する領域だ。例えば、Claude Codeでは「BUGS.md」「DECISIONS.md」のような補助ファイルを併用して、セッションをまたいだ作業継続性を担保する設計が公開されている。

共通ナレッジベースとチーム横断の文脈共有

「個別更新が無意識にチーム全体に反映される」観点では、各社のコネクタ機能と社内ナレッジ統合がポイントになる。

Gemini Code Assist Enterpriseは「プライベートコードベースに基づくコードカスタマイズ」を提供しており、社内コードリポジトリを直接参照したコード提案が可能。チーム横断の文脈共有という観点では、Gemini Enterpriseが構造的に有利な側面がある。

3サービスの「ひとり開発→チーム開発」移行のしやすさ

筆者の現状はClaude Code（個人Max 5x）でひとり開発。チーム展開を考えるとき、どのサービスが移行しやすいかを整理すると以下になる。

既存IT資産がGoogle WS中心なら、認証統合と社内データ参照の容易さでGemini Code Assistが有利。逆にコーディングエージェントのノウハウ・コミュニティ蓄積を重視するならClaude Code、社内全体（開発以外含む）にAIを広げる土台としてはChatGPT Enterpriseが選択肢になる。

SE業務適性で見た3サービスの判断軸まとめ

既存IT資産で選ぶ場合の判断軸

会社で既に何を使っているかが、最大の決定要因になることが多い。

コーディング業務の主軸で選ぶ場合の判断軸

開発業務の中身で選ぶなら、次の軸で判断する。

組織展開フェーズ別の選び方

導入フェーズでも選び方が変わる。

• フェーズ1（実験段階・10人以下）：個人プランまたはTeam（Claude Team Premium / ChatGPT Business / Code Assist Standard）でスモールスタート
• フェーズ2（部署展開・10〜50人）：Team Premiumまたは Code Assist Enterpriseで開発組織に絞って展開
• フェーズ3（全社展開・50人〜）：エンタープライズプラン交渉（特にClaudeは20シート、ChatGPTは150シートが境界）

実際に提案を進める前段として、まず社内のAI利用ルールを整える必要がある。社内AIガイドラインで決めるべき5論点を整理してからプラン選定に入ると、ツール選定と運用ルールの整合性が取りやすい。

ムラサキ

個人で触っているClaude Codeの感覚で「Claude一択」と言いたくなるが、会社の前提（Workspace中心）を踏まえるとGemini Code Assistの認証統合メリットは大きい。筆者の社内ではまずCode Assist Standardのライセンス確認から始めるのが現実的な第一歩、と整理した。比較記事を書く過程で、自分の選定軸が「個人ノウハウ」から「組織前提」に切り替わったのが収穫だった。

よくある質問

まとめ

ChatGPT・Claude・Geminiのエンタープライズ・有料プランは、SE業務向けに9軸で比較すると構造の違いが鮮明になる。料金モデルはハイブリッド型（ChatGPT）・フル従量寄り（Claude）・固定費寄り（Gemini）と分かれ、API利用の扱いも3社で全く違う。コーディングエージェントは機能面で横並びに近づいてきており、選定の決め手は「既存IT資産との整合性」「組織のチーム情報共有設計」「コスト構造の予測しやすさ」の3点に集約される。

個人プランの体感で「Claude一択」のような直感的判断は通用しないのが、エンタープライズAI選定の現実だ。会社の前提（既存資産・組織規模・開発スタイル）から逆算して、3社のどれが整合するかを見極めるのが実用的なアプローチになる。

社内提案を進める前段では、ツール選定と並行してガイドライン策定の5論点を整理しておくと、運用ルールとプラン選定が一体で議論できる。なお、API経由で参照データをカスタマイズし、自社サービスにカスタムAIを組み込む構成については、別記事で実装ベースの整理を予定している。

2026.04.04 更新：Claude Opus 4.6の100万トークン正式GA反映、アイキャッチ運用をCanvaに変更、ワークフローのフロー図追加、内部リンク配置の改善

ChatGPT、Gemini、Claude、Copilot――2026年現在、ブログ記事の作成に使える生成AIは数えきれないほど増えました。「AIを使えばブログが楽になるらしい」と聞いて調べてみたものの、どれを使えばいいのか結局わからない。そんな状態で止まっている方は多いのではないでしょうか。

この記事は、AIツールの機能比較やランキングではありません。SE歴20年・副業ブログ運営中の筆者が実際にClaudeというAIを使い、キーワード選定から下書き投稿まで全工程を回してみた実践記録です。便利だった点も困った点も隠さず書いています。AIでブログを始めたいけど最初の一歩が踏み出せない方の判断材料になれば幸いです。

AIでブログを書きたいけど何を使えばいいかわからない人へ

2026年4月時点で、ブログ記事の作成に使える主なAIだけでもChatGPT、Gemini、Claude、Copilot、Perplexityと多岐にわたります。それぞれ無料プランがあり、どれも「記事が書ける」とうたっています。選択肢が多すぎて比較記事を読んでも決められない、という状況は珍しくありません。

筆者も同じ状態でした。最終的に選んだのはClaudeですが、「Claudeが最高だから」ではなく「たまたまClaudeを使い始めて、そのまま全工程を回せた」というのが正直なところです。この記事では、そのリアルな経緯と実際の運用方法をそのままお伝えします。

筆者がClaudeを使い始めた経緯

生成AIの話題をニュースやCMで頻繁に見かけるようになり、興味本位でGenSpark（ジェンスパーク）というAIプラットフォームを触り始めたのがきっかけです。

以前にもサイト運営をしていた時期がありましたが、構成検討や執筆、画像準備といった作業に時間を取られて続きませんでした。生成AIでその負担が減らせると感じ、2026年2月にサイト運営を再開しています。今思えばこの生成AIの流れに乗るために課金する材料を集めていたような節もあります。

GenSparkのAIチャットでは複数のモデルを選択して使えます。公開ベンチマークを見比べた結果、最もスペックが高そうだったClaude Opus 4.6を選び、そのままブログ運営の全工程で使うようになりました。GenSparkの有料プラン（Plus）ではAIチャットがクレジット消費ゼロの無制限利用になるため、記事作成を頻繁に行う筆者にとってコストパフォーマンスは高く、課金判断の詳細はGenspark有料版レビューにまとめています。

Claudeはブログ記事の執筆だけでなく、コーディングでも強力です。Claude無料版を使って業務システムを2週間で開発した全工程をバイブコーディングの実践記にまとめています。

その後Claude Codeに移行してWebサービス開発まで発展した。コスト管理・暴走対策を含む個人開発の実録に続きがある。

2026年4月にはOpus 4.6の後継となるOpus 4.7が料金据え置きでリリースされた。副業開発でのSonnet/Opusの使い分け基準はOpus 4.7の副業開発での使い分けで整理している。

Claudeでブログ記事を作る具体的な手順

筆者がClaudeを使ってブログ記事を1本公開するまでの流れを紹介します。すべてAIに丸投げではなく、自分で判断する部分とAIに任せる部分を分けて運用しています。

リサーチ段階では複数のAIを組み合わせると精度が上がります。筆者は情報収集にGensparkを使っています。

ブログ記事をAI音声に変換してYouTube動画として再利用する方法もあります。ElevenLabsを使えば、書いた記事をそのまま動画ナレーションに転換できます。具体的な手順はブログ記事をAI音声でYouTube動画化する副業ワークフローで解説しています。

キーワード選定──自分の経験とAIの両方で洗い出す

キーワードは自分の経験から「これを知りたかった」という実感をベースに候補を出す場合と、Claudeに関連キーワードを洗い出してもらう場合があります。最終的にどのキーワードで書くかは自分で決めます。自分が実体験として語れるテーマかどうかが判断基準です。

記事構成・本文・HTML生成をAIに任せる

キーワードが決まったら、自分の経験や伝えたいことをClaudeにインプットし、記事構成を作ってもらいます。構成段階で内容の不整合や意図と異なる解釈がないかをチェックし、修正を指示します。

構成確定後は本文執筆からHTML化まで一気に依頼します。WordPressのCocoonテーマに対応したブロック構文で出力させるため、コピー＆ペーストで綺麗に整形された記事ができあがります。

スプレッドシートからMake経由でWordPressに自動投稿

生成されたHTMLはGoogleスプレッドシートに転記し、Make（旧Integromat）でWordPressに下書き投稿しています。タイトル、本文、スラッグ、カテゴリーなどを1行にまとめておけば、ボタンひとつで下書きが作成される仕組みです。

graph TD
    A["キーワード選定"] --> B["記事構成の作成"]
    B --> C["本文・HTML生成"]
    C --> D["スプレッドシートに転記"]
    D --> E["アイキャッチ画像作成"]
    E --> F["Google Driveに<br>アイキャッチをアップ"]
    F --> G["Make検知 →<br>アイキャッチ付きで<br>WordPress下書き投稿"]
    G --> H["プレビュー確認・編集"]
    H --> I["公開"]
    A -.- A1["自分の経験 +<br>Claudeで候補洗い出し"]
    C -.- C1["Cocoonブロック構文で<br>HTML出力"]
    E -.- E1["Canvaテンプレートで<br>統一デザイン"]
    F -.- F1["Driveアップが<br>Makeのトリガー"]
    style A fill:#e3f2fd,stroke:#90caf9
    style B fill:#e3f2fd,stroke:#90caf9
    style C fill:#e3f2fd,stroke:#90caf9
    style D fill:#fff3e0,stroke:#ffcc80
    style E fill:#fff3e0,stroke:#ffcc80
    style F fill:#fff3e0,stroke:#ffcc80
    style G fill:#e8f5e9,stroke:#a5d6a7
    style H fill:#fff3e0,stroke:#ffcc80
    style I fill:#f3e5f5,stroke:#ce93d8
    style A1 fill:#fafafa,stroke:#e0e0e0
    style C1 fill:#fafafa,stroke:#e0e0e0
    style E1 fill:#fafafa,stroke:#e0e0e0
    style F1 fill:#fafafa,stroke:#e0e0e0

青がAI支援工程、緑が自動化工程、オレンジが手動工程です。スプレッドシートに記事データを転記した後にCanvaでアイキャッチ画像を作成し、Google Driveにアップロードすると、Makeがそれを検知してアイキャッチ付きのWordPress下書き投稿を自動生成します。

Makeを使った自動投稿の全体設計に興味がある方もいるかもしれません。ブログ公開からX投稿まで自動化する具体的なシナリオ構成はMake副業自動化入門｜ブログ→X投稿を自動化した全手順で解説しています。

プレビュー確認とアイキャッチ画像の選定

下書きがWordPressに投稿されたら、プレビュー画面で表示を確認します。見出しの階層、装飾ブロックの表示崩れ、文章のつながりなどを目視でチェックし、必要に応じて手動で修正します。AIの出力をそのまま公開することはほぼありません。

アイキャッチ画像は当初GenSparkの画像生成機能で作成していましたが、文字の崩れや構図の問題があり、現在はCanvaでテンプレートベースで作成する運用に切り替えています。テンプレートにタイトルとステップ文言を流し込むだけで統一感のあるアイキャッチが完成します。AI画像生成ツールの比較と筆者が辿り着いたワークフローはAI画像生成でアイキャッチ作成｜無料5ツール比較で詳しく紹介しています。

公開後に記事間の不整合が見つかった場合は、Claudeに調査を依頼しますが、修正の反映は手動で行っています。

AIブログの書き方で感じたデメリットと対処法

便利な点が多い一方で、困ったことも正直にあります。GenSpark経由で使っているため、問題の原因がClaude側かGenSpark側か切り分けできていない部分もあります。

AIに任せると効率は上がるが、その裏で数字が捏造される事故も起きる。AIが数字を捏造した実例と防止策に、本番公開でやらかした一件をまとめた。

同じ文言の繰り返し・コンテキスト忘れ

同じフレーズが重複して出力されることがあります。原因は特定できておらず、有効な対処法も見つかっていません。都度手動で削除しています。

また、同じチャットで長く会話を続けていると、序盤に共有した情報が抜け落ちることがあります。「さっきと同じ形式で続けて」と指示しても体裁の異なる結果が返ってきます。重要な情報はプロンプトに都度再掲して対処していますが、手間は増えます。

アイキャッチ画像が1回で期待通りにならない

当初はAIに画像生成プロンプトを作らせてGenSparkで生成していましたが、文字の崩れや非現実的な構図が頻発し、1回で想定通りになることはまれでした。この問題はAI画像生成ではなくCanvaのテンプレートでアイキャッチを作成する方式に切り替えることで解決しています。AI画像生成の限界と代替ワークフローの詳細はアイキャッチ作成ツール比較記事にまとめました。

画像生成AI以外のアプローチとして、Claude DesignでHTMLベースのアイキャッチ素材を作りブラウザでスクショする手順もある。検証結果はClaude Designの実測レポートにまとめた。

対処できたこと・できていないこと

コードの出力が1行に詰め込まれて読みにくい問題は、出力ルールの再定義で改善しました。コードブロックに言語クラスを付与し、Cocoonのシンタックスハイライト機能を有効にすることで視認性が大幅に向上しています。

文言の重複やコンテキスト忘れは現時点で根本的な対処ができていません。AIですべてが自動化されるわけではなく「AIが苦手な部分を人間が補う」前提で運用するのが現実的です。この「面倒を1つずつ潰す」発想はWindows環境の業務自動化にも通じており、SE歴20年の業務自動化術でSendToカスタマイズからSeleniumまで現場のテクニックをまとめています。

よくある質問（FAQ）

Claude Codeを使った開発効率化をさらに深めたい場合は、ターミナル内チュートリアル機能の解説記事Claude Code /powerup入門も役立つ。

実際にこのワークフローでブログを2ヶ月運営した結果、ツール構成はClaude Code Maxへの集約に落ち着いた。出費と成果の推移を含む詳細データは運営報告で公開している。
副業ブログ2ヶ月目のデータ全公開

まとめ｜AIツール選びより「まず1本書く」が最短ルート

この記事では、筆者がClaudeを使ってブログ記事を作成している実際のワークフローと、使ってみて感じたメリット・デメリットを紹介しました。このワークフローで実際に1ヶ月運営した結果（PV200・収益0円・出費16,266円）は副業ブログ1ヶ月目の収支レポートで全数字を公開しています。

ポイントを振り返ると、GenSparkの無料AIチャットからClaude Opus 4.6を選び、キーワード選定から下書き投稿まで一連の工程を構築できたこと。構成チェックや画像選定など人間が介入する工程は残ること。重複出力やコンテキスト忘れなど未解決の課題もあること。この3点です。

AIツール選びで比較記事を読み続けるよりも、まず1本書いてみる方が圧倒的に早く前に進めます。合わなければ別のツールに乗り換えればいいだけです。10年前に挫折した筆者でも再開できたのは、AIが「本質ではない作業」を引き受けてくれたからでした。

それから約半年後の2026年3月、Claude無料版を使ったバイブコーディングで、音声対話型のAIヒアリングシステムを2週間で開発しました。この記事では、設計から実装、トライアンドエラーの記録、月額$7〜8のコスト内訳まで、開発の全工程を包み隠さず公開します。

ムラサキ

2025年に心が折れた人にこそ読んでほしい記事です。AIのコード生成能力は半年で別物になっています。

バイブコーディングとは？2025年との決定的な違い

バイブコーディングの定義と基本の流れ

バイブコーディング（Vibe Coding）とは、AIに自然言語で「こういうものを作りたい」と指示し、コードを生成させる開発手法です。2025年にOpenAI共同創設者のAndrej Karpathy氏が提唱した概念で、従来のプログラミングのように構文を1行ずつ書くのではなく、AIとの対話を通じてシステムを構築していきます。

基本的な流れは「何を作りたいかを言葉で説明する → AIがコードを生成する → 動作を確認する → 問題があれば修正を指示する」の繰り返しです。使うツールはClaude Code、Cursor、ChatGPTなど複数ありますが、筆者はclaude.aiの無料プランを使いました。

2025年8月の挫折と2026年3月の成功

筆者は2025年8月にGitHub CopilotとChatGPTを使い、VSCodeの拡張機能からSQLフォーマッターを抜き出してWinMergeのプラグインに組み込む開発を試みました。結果は惨敗です。不具合が出るたびにAIが提案する修正が二転三転し、4回5回と方針が変わった末に答えにたどり着けませんでした。

2026年3月、Claude Sonnet 4.6がリリースされたタイミングで再挑戦しました。Anthropicの公式リリースによると、Sonnet 4.6はコーディング能力とエージェント的なタスク遂行能力が大幅に向上しています。実際に使ってみて、コード生成の正確性と文脈保持能力が2025年のツールとは別物だと感じました。半年でここまで変わるのかと驚いた、というのが率直な感想です。

今回作ったもの｜AIヒアリングシステムの概要

システムの全体像と機能

開発したのは、社内の採用業務で使うAI事前ヒアリングシステムです。エンジニア候補者に対して、面接前の事前確認をAIが自動で実施します。候補者はURLにアクセスするだけで音声による対話形式のヒアリングを受けられ、管理者は結果の確認と採否判定を行えます。

graph LR
    A["候補者ブラウザ"] -->|"音声録音"| B["React/Viteフロントエンド"]
    B -->|"API通信"| C["Node.js/Expressバックエンド"]
    C --> D["MongoDB Atlas候補者データ"]
    C --> E["AWS S3音声保存"]
    C --> F["Claude Haiku 4.5AI対話・評価"]
    C --> G["Whisper API音声→テキスト"]
    C --> H["Google TTSテキスト→音声"]
    style A fill:#e8f0fe,stroke:#4a86c8
    style B fill:#e8f0fe,stroke:#4a86c8
    style C fill:#e8f4e8,stroke:#5a9e6f
    style D fill:#f5f0e8,stroke:#c4a96a
    style E fill:#f5f0e8,stroke:#c4a96a
    style F fill:#f0e8f5,stroke:#9a7ab5
    style G fill:#f0e8f5,stroke:#9a7ab5
    style H fill:#f0e8f5,stroke:#9a7ab5

主な機能は、候補者向けのURL発行・音声対話・イニシャル表示による本人確認、管理者向けの候補者一覧・会話履歴確認・音声再生・評価レポート自動生成・採否判定です。AIは「面接官」ではなく「事前ヒアリング担当」として振る舞い、採否判断は一切行わない設計にしました。

技術スタックとコスト

初期費用はほぼ0円です。各サービスの無料枠で開始できました。2026年3月時点のランニングコストは月額約$7〜8で、内訳は以下の通りです。

Renderの料金ページによると、有料プラン（Starter $7/月）に上げるとスリープがなくなり本番運用に適した状態になります。MongoDB Atlasの無料枠（M0）は512MBのストレージを提供しており、開発・検証段階では十分です。Whisper APIは1分あたり$0.006と安価で、ヒアリング1回30分でも約$0.18です。

開発フローの実際｜環境制約でAIを使い分けた経緯

設計フェーズ ── Gemini Proで壁打ち

設計段階は本業の延長で進めていたため、Google WorkspaceのGemini 3.1 Proを使いました。アーキテクチャの検討、技術スタックの選定、コスト試算、開発ロードマップの策定をGeminiとの壁打ちで詰めていきました。

Geminiが得意だったのはアーキテクチャの比較検討です。「ターン制のREST API方式」と「WebSocketによるリアルタイム方式」の2パターンを提示させ、コスト・開発期間・UXのトレードオフを整理してもらいました。結論として、コスト優先でREST API方式を選択しています。

設計からコーディングへの情報の受け渡し

設計が固まった段階で、コーディング用の環境を準備しました。業務で使っているPCはソフトウェアのインストールが制限されており開発環境を構築できないため、別途スタンドアロンの開発用PCを用意しています。この開発用PCからはGoogle Workspaceに接続できないため、ブラウザだけで利用できるclaude.aiの無料プランをコーディング用AIとして選びました。

AIを乗り換える際に重要だったのが、設計フェーズで決めた内容の受け渡しです。Geminiとの長いチャット履歴をそのまま渡しても、過去のボツ案と最終決定をClaude側が混同してしまいます。そこでGeminiに「引き継ぎ用のドキュメントを作って」と依頼し、決定事項・進捗・次のアクションだけを圧縮した要約を作成しました。これをClaudeの最初のメッセージとして投げることで、情報のロスなく実装フェーズに移行できました。

実装フェーズ ── 無料のclaude.aiでバイブコーディング

claude.aiの無料プランでClaude Sonnet 4.6を使い、フロントエンド（React/Vite）・バックエンド（Node.js/Express）・各種API連携のコードを書いていきました。開発期間は2026年3月初旬から3月13日までの約2週間です。

驚いたのは、1つのチャットの中でフロントからバックエンド、API連携まで一貫して対応できたことです。以前のAIコーディングツールでは長いやり取りの中で方針がブレたり、過去の指示を忘れたりすることがありましたが、Claude Sonnet 4.6ではプロジェクト全体の流れを保ったまま開発を進められました。筆者がClaudeをブログ執筆に活用しているワークフローはClaudeでブログ記事を作成する実践ワークフローで公開していますが、記事作成とは異なり、バイブコーディングでは1つの長いチャットで完結できた点が印象的でした。

ぶつかった壁と解決策

開発中にぶつかった問題は10件以上あります。ここでは特に印象的だった3つを紹介します。

音声合成の選定 ── VOICEVOX → Google Cloud TTSへの移行

当初は無料の音声合成エンジンVOICEVOXを使用していましたが、Render環境での動作が不安定でした。ローカルでは問題なく動くのに、サーバー環境との相性が悪かったのです。この問題をClaudeに相談したところ、Google Cloud TTSのNeural2音声（ja-JP-Neural2-B）への移行を提案してきました。その通りに試したところ、自然な日本語音声を安定して生成できるようになりました。原因の切り分けから代替案の提示まで的確で、こいつやるなと感じた場面です。

AIが採否判断を下す問題

テスト中にAIが候補者に「この案件への参画は難しい判断となります」と直接断りを告げた場面がありました。ヒアリングシステムなのにAIが勝手に合否を伝えてしまうのは致命的です。プロンプトに「採否・合否・参画可否の判断は絶対にしないこと」「難しい・厳しいなど断りを示唆する表現は一切使わないこと」を明記して対処しました。バイブコーディングでは機能の実装だけでなく、AIの振る舞いの制御にも注意が必要です。

ムラサキ

AIが「情報収集に徹する」のか「判断まで下す」のかはプロンプト設計で明確に線引きする必要があります。ここをサボると本番で事故が起きます。

個人情報とファイルアップロードの方針転換

当初はスキルシートのPDF/画像をアップロードしてClaude APIで自動解析する機能を実装しました。しかし、外部のクラウドサービスに候補者の個人情報（氏名・住所等）を含むファイルを送信するリスクを考慮し、この機能は削除しました。代わりに、社内のセキュアな環境でスキルシートの個人情報をマスクしたテキストを作成し、システムにはマスク済みの情報のみを登録する運用に変更しています。個人情報を扱う部分は社内の閉じた環境に留め、外部に出るシステムには匿名化された情報だけが渡る設計です。

機能をまるごと削除する判断は一見もったいなく見えますが、むしろこれはバイブコーディングの強みが発揮された場面でした。AIに「この機能を削除して、関連箇所もすべて整合を取って」と指示すれば、一括で対応してくれます。人間がコードを手動で修正すると関連箇所の修正漏れ（デグレード）が起きるのが常ですが、AIはそのリスクを大幅に下げてくれました。AIの出力を検証・判断する力の重要性については生成AI時代に必要なスキルと若手教育の進め方でも解説しています。

バイブコーディングを成功させるコツと注意点

実装速度が上がるほどレビューの抜け漏れリスクも増える。LLMコードレビュー4手法の実測比較で、Claude Code 内蔵レビューを追加コストゼロで回す方法を解説している。

プログラミング経験があると何が有利か

バイブコーディングは「コードを書けなくてもアプリが作れる」と紹介されることがありますが、実際にはIT業界の用語や概念を知っているかどうかで、AIとのやり取りのスムーズさが大きく変わります。筆者自身、今回の開発でReactもNode.jsも手では書けませんし、生成されたコードの中身を読んで理解するというプロセスは一切踏んでいません。修正時にキーワード検索で該当箇所を目にすることはありますが、コードリーディングと呼べるものではありませんでした。

それでも2週間でシステムが完成したのは、S3・React・Node.js・環境変数・Gitといった用語をSEとして実務で利用していなくても知識があったため、AIとのキャッチボールがスムーズだったことが大きいと感じています。エラーが出たときも、エラーメッセージをそのままコピペするかスクリーンショットを貼るだけで、AIが原因を特定して修正案を出してくれました。長年コードレビューを担当してきた中で「ここは壊れやすい」「この設計だと後で困る」といった勘所が自然と身についていたことも、問題の早期発見に役立ったのかもしれません。

一方、これらの用語自体が初めての方は、AIへの質問を組み立てる段階で時間がかかります。バイブコーディング自体が不可能になるわけではありませんが、筆者の2週間という期間はこうした前提知識があっての数字です。筆者が実務で使っている業務自動化テクニックで紹介しているようなWindows標準機能やPowerShellの知識も、開発環境の構築で役立ちました。

経験があるとスケールも早い。Batch APIと組み合わせた3日間・713ページのpSEOサイト構築という規模感がその一例だ。

無料AIの制限との付き合い方

claude.aiの無料プランには数時間ごとのメッセージ上限があり、開発中に何度か上限に達しました。ただし本業の傍らで進めていたため、上限リセットまでの待ち時間は別の業務に充てられ、実質的な問題にはなりませんでした。それでも効率を意識した点が2つあります。

• エラー発生時はエラーメッセージをそのままコピペするかスクリーンショットを貼り付ける。自分で原因を解説しようとするより、生のエラー情報を渡す方がAIの回答が的確で早い
• 上限に達したらChatGPT（GPT-4oの無料枠）で軽い調査を進め、Claudeが復帰したらメインの開発に戻る

無料の範囲でも、今回のシステム規模（フロント1ファイル・バックエンド1ファイル・管理画面1ファイル）なら十分に開発を完了できました。

妥協の判断基準

すべてを理想通りに実装しようとすると、無料枠の制限や開発期間の中では終わりません。筆者は以下の基準で妥協を判断しました。

「8割の精度で動くものを素早く作り、使いながら改善する」のがバイブコーディングの強みです。完璧を目指して動かないより、まず動くものを完成させる方が結果的に早く前に進めます。

よくある質問（FAQ）

まとめ

この記事では、Claude無料版を使ったバイブコーディングで業務システムを2週間で開発した全工程を紹介しました。要点を3つに絞ります。

バイブコーディングは「完璧なコードを一発で書く」ツールではなく、「試行錯誤のサイクルを高速に回す」ツールです。ぶつかった壁は10件以上ありましたが、そのすべてをAIとの対話で解決できました。作りたいものがあるなら、まず小さな機能1つから始めてみてください。

ムラサキ

2025年に心が折れた筆者が、半年後にシステムを完成させられました。AIの進化を待っていた人は、そろそろ動き出すタイミングです。

SE歴20年・Claude Max 5x契約の筆者が、リリース翌日に2件のプロトタイプを実測しました。BtoB比較サイトのLP改善案と、モバイルWebアプリのマッチング画面です。URL参照の挙動・Tweaks機能・Export形式・クォータ消費量まで一次体験で記録したレポートをまとめます。

ムラサキ

最初は画像生成AIかと思ったら違いました。Claude Designの正体と、触ってわかった向き・不向きを一次情報で整理します。

Claude Designは画像生成AIではない

「Design」という名前から画像生成ツールを想像しがちですが、Claude Designが作るのはプロトタイプ・スライド・LPなどのHTMLベースの成果物です。Anthropicの公式Xアナウンスでも「prototypes, slides, and one-pagers」と位置づけられており、Figma・Canvaに近い立ち位置になります。

2026年4月17日リリースの研究プレビュー

Claude DesignはAnthropic Labs（同社の実験的プロダクト部門）から公開された研究プレビュー機能です。Pro・Max・Team・Enterpriseの有料プランで段階的に利用可能となり、Web版のclaude.ai/designからアクセスできます。

前日の4月16日にはClaude Opus 4.7が一般公開されており、Claude DesignはこのOpus 4.7の視覚理解能力を前提に設計されています。Opus 4.7は最大解像度が従来の1568pxから2576pxへ大幅に拡張され、デザイン用途のスクリーンショット解析が現実的になったモデルです。Opus 4.7自体の位置づけとコスト感はOpus 4.7と副業開発への影響を整理した記事で詳しく扱っています。

作れるもの・作れないもの

Claude Designで作れるのはWebページ・アプリのプロトタイプ、スライドデッキ、ワンページャー、マーケティング資料などです。いずれもHTMLベースで生成され、ExportメニューからZIP・PDF・PPTX・standalone HTMLで書き出せます。

一方で作れないものもはっきりしています。MidjourneyやStable Diffusionのような写真風画像生成、動画・アニメーションの生成、実データと連携した動的ダッシュボードなどは範囲外です。

モデル選択はOpus 4.7がデフォルト、切替も可能

Claude Designの入力欄左下の歯車アイコン（Change model）からモデルを切り替えられます。選択肢はClaude Haiku 4.5・Opus 4.7（デフォルト）・Sonnet 4.6・Opus 3・Opus 4.6・Sonnet 4.5の6種類。筆者の3件の検証はすべてデフォルトのOpus 4.7で実施しました。軽めの編集指示ならHaiku 4.5やSonnet 4.6に落とすことでクォータ節約が可能な設計になっています。

検証1｜BtoB比較サイトのLP改善

1件目は「SaaSツールを比較する情報サイトのLP」を題材にしました。現状サイトのURLを参考情報として渡し、コンバージョン重視のリデザイン案を依頼する形です。

投げたプロンプトと事前準備

Claude Designの新規プロジェクト作成は、Prototype（プロトタイプ）／Slide deck（スライド）／From template（テンプレート）／Otherの4タブから選びます。Prototypeの下にはWireframe（ラフ）とHigh fidelity（高精度モックアップ）の2モードがあり、今回はHigh fidelityを選択しました。

Createボタンを押すと、左ペインにチャット入力欄、右ペインにキャンバスが表示される作業画面に遷移します。コンテキスト追加ボタンとしてDesign System／Add screenshot／Attach codebase／Drag in a Figma fileの4種が用意されており、ブランド資産やコードベースを事前に紐付けられる設計です。

今回は事前アセットは渡さず、プロンプト本文内にURLだけを含めて投げました。実際に使ったプロンプトの骨格は次の通りです。サイト情報・現状課題・ターゲット・依頼内容・バリエーション数を明示しています。

https://example.com を参考にして、このLPを改善してほしい。

【サイトの目的】
SaaSツールを探している人向けの比較・レビューサイト

【現状の課題】
- ファーストビューで何のサイトか伝わりにくい
- CTA（資料請求・比較ボタン）の導線が弱い

【ターゲット】
情報収集段階の中小企業のIT担当・個人事業主

【依頼】
- コンバージョンを意識したLPトップページのデザイン案
- クリーンで信頼感のあるテック系（BtoB寄り）
- バリエーションは2案まで（トークン節約のため）

Fetching挙動｜URLを渡すと実際にサイトを読みに行く

プロンプト送信後、Claude Designは逆質問をせず即座に生成フェーズに入りました。左ペインには「依頼内容がかなり具体的（方向性・必須要素・バリエーション数まで指定済み）なので、前提をまとめて即着手します」という宣言が表示され、続いてデザイン方針（アプローチ・タイポグラフィ・カラー・構造）を明示したうえでProgress 0/4のタスクリストを展開します。

進行中のアクション表示には「Fetching page ×2, Copying starter」の文言が出ました。URLを渡すとClaude Designがweb capture toolでサイトを実際に取得しに行くことが、この表示で確認できます。ただし丸ごとコピーはせず、「著作権に配慮し、コピーではなく『BtoB向けSaaS比較サイト』として一般的なパターンで新規設計します」と宣言したうえで、参考サイトの雰囲気だけを汲む挙動でした。

数分で完成したLPファーストビュー

プロンプト送信から完成まで数分。筆者が別で実測した軽量LP案件では約6分で完走しました。右ペインにindex.htmlとして1ファイルのLPが出力され、ファーストビューのコピーは「『使うべきSaaS』が、30秒で見つかる。」。ターゲット文言（中小企業のIT担当・個人事業主）はプロンプトから引用され、CTA2種（無料で比較をはじめる／比較シートをダウンロード）・信頼数値（320+ 掲載SaaS／18 カテゴリ／月間 42k 意思決定者）・比較表サンプル・カテゴリ導線・代表ツールの横スクロールまで、依頼した必須要素がすべて1ページに収まっています。

注意点として、比較表に記載されたツール名（Notion・Confluence・Coda等）は実在するサービスですが、料金・スコア数値はダミーです。Claude Designは実データ連携を持たないため、具体的な数値を使う最終版には必ず自力で差し替えが必要になります。

Tweaks機能｜配色とコピー文言まで変わる

右上の「Tweaks」トグルをONにすると、生成された2バリエーション（案A / Navy・案B / Ink）を即時切替できます。面白いのは配色だけでなくコピー文言まで変わる点で、案Aの「『使うべきSaaS』が、30秒で見つかる。」に対して案Bは「SaaS選びの、最短ルート。」と別のメッセージが自動生成されていました。

単なるテーマ切替ではなく、各案が独立した別デザインとして成立するように設計されている点が特徴です。プロンプトで「王道BtoB」「モダン・差別化志向」という2方向を事前に指示できれば、2案を並べて社内議論のたたき台にする使い方が現実的になります。

検証2｜モバイルWebアプリのマッチング画面

2件目はポケモンGOの個体交換マッチングサービスを想定し、マッチング結果一覧画面（/matches）を言語説明だけで起こしました。URL参照ではなく、複雑な業務仕様をテキストで指示したときにどこまで再現できるかの検証です。

言語だけでの指示プロンプト

プロンプトには、サービス概要（何を何とマッチングさせるか）、画面構成（上部タブフィルター・セクション見出し）、マッチカードの2カラム構造、バッジ・状態表現のルール、アクションボタンの表示条件、モバイルファースト（375px想定）などを詳細に記述しました。ドメイン固有の用語（双方向マッチ／片方向マッチ／フレンドレベル不足／ほしのすな消費量）がどこまで伝わるかもチェックポイントです。

375px固定のiOSフレーム付きUIで完成

送信から完成までは数分。Progressタスクは0/7まで分解され（iOSフレーム取り込み・マッチデータ設計・カード実装・タブフィルター実装・リクエストモーダル実装・状態遷移管理・仕上げ検証）、生成ファイルはapp.jsx・modal.jsx・card.jsx・components.jsx・data.jsx・ios-frame.jsxの6つのReactコンポーネントに分割されていました。

完成画面はiPhoneフレームに9:41の時刻表示とノッチが再現され、内部のUIは375px固定幅で収まっています。タブフィルター（すべて8／アクション可能2／交渉中2）の件数バッジ、双方向マッチセクション（4件）の緑バッジ、マッチカード2枚の左右2カラム表示（自分のリスティング／相手のリスティング）、トレーナー名＋取引実績バッジ、ほしのすな消費量、スケジュール重複時間、黄色の「リクエストする」CTAボタン、下部タブバーのチャットアイコンに付く通知バッジまで、指示した仕様がほぼそのまま反映されています。

著作権配慮のガードレール｜固有名詞は許容、公式UIは回避

興味深かったのは、ポケモン名（ラルトス・ヨーギラス・ヒトカゲ・ゼニガメ）と図鑑番号はサンプルデータとして採用しつつ、「ポケモンGO自体の画面やロゴは使わず、オリジナルの『個体交換マッチングサービス』としてデザインします」と宣言したうえで公式UIの模倣を回避した点です。実際、マッチカード内のポケモン画像はオリジナルのモンスターボール風プレースホルダ（タイプ色で塗り分け）に置き換えられていました。

固有キャラ名の例示は許容、公式UIやロゴの模倣は回避というガードレールの粒度が、検証1（BtoBサイトの丸コピー回避）と合わせて見えてきます。商用利用前の最終確認は必要ですが、著作権リスクへの一定の配慮が組み込まれている設計です。

日本語フォント選定の文化的配慮

フォント選定は検証1と検証2で明確に違いました。BtoB LP（検証1）ではPlus Jakarta Sans＋IBM Plex Monoという英文ベース、モバイル・カジュアル・日本ユーザー想定の検証2ではZen Maru Gothic＋M PLUS Rounded 1cという丸ゴシック系日本語フォントが選ばれています。プロンプトに「日本語フォント」とは書いていないにもかかわらず、文脈から自動で使い分ける挙動です。

追加検証で見えた、アフィリLPとTweaksの多軸性

上記2件とは別に、アフィリエイト記事向けのVPN比較LPを3件目として検証しました。この検証はトピックが重複するので本記事には含めませんが、2点の新発見があったので補足します。1件あたりのClaude Design枠消費は+15%、生成時間は実測で約6分でした。

景表法・PR表記を自発的に挿入

アフィリエイト目的のLP生成では、プロンプトで明示していないにもかかわらず「PR・景表法表示：本ランキングはアフィリエイト広告を含みます。評価は編集部の独自基準によるもので、広告料によって順位は変動しません」というステマ規制対応の注記がファーストビュー直下に自動挿入されていました。依頼内容から「アフィリエイト収益化視点」というキーワードを汲み、景表法・ステマ規制への配慮を自発的に入れる挙動です。

Tweaksはコンテンツに応じて多軸化する

検証1のTweaksは「案A/案B」の2バリエーション切替でしたが、VPNランキングLPでは「デザイン方向（A・ネイビー/B・ダークグリーン）」「見出し言語（日本語/日+英併記）」「ランキング密度（詳細(Pros/Cons)/コンパクト）」の3軸同時カスタマイズに変化していました。固定のUIパターンではなく、生成物の性質に応じてカスタマイズ軸が動的に組み立てられている挙動です。ランキングLPなら密度軸、2方向のデザイン比較なら方向軸、といった最適化が入っていると見られます。

できること・できないことの整理

3件の検証から見えた範囲を整理します。2026年4月時点の研究プレビュー版での筆者検証範囲内での結果です。

できること

できないこと・注意点

エンジニアの現実的な使い道3パターン

副業SEや週末起業家の視点で、実務に組み込める使い方を3つ整理しました。

クォータ設計の実測ガイド

研究プレビュー期間中のClaude Designで最も重要なのがクォータ設計です。Claude Designには通常のClaude利用枠とは別のトークン枠が設定されており、消費ペースが想像以上に速いことが報告されています。

Claude Design枠は通常枠と別カウント

Claudeの設定画面の使用量タブを開くと、「すべてのモデル」「Sonnetのみ」に加えて「Claude Design」の独立した枠が確認できます。リセット時刻も通常のモデル枠（筆者環境では金曜7:00）と異なり、Claude Designは土曜21:00と別設定。Designをヘビーに使っても通常のチャット枠は残る、逆にチャット枠を使い切ってもDesignは動く、という住み分けです。

Max 5x実測：検証1本あたり約9〜15%消費

Claude Max 5xプランでの実測値を3件並べると、検証1（LP 2バリエーション＋URL fetch）で13%消費、検証2（モバイル画面1案）で9%消費、追加検証のVPNランキングLP（3軸Tweaks付き）で15%消費でした。合計37%で3本のプロトタイプを完走しています。単純換算で、Max 5xなら週次で6〜10本程度の本格プロトタイプが作れる計算になります。

一方Proプランの実測については、PCWorldのBen Patterson氏の検証記録が参考になります。同氏は3バリエーションのプロトタイプ生成を25分で完走したものの、その時点でProの週次Claude Design枠の80%を消費。誤操作のundoで全作業が消えた後5分間の再生成で残り枠もゼロになったとレポートしています。本格的にプロトタイプを作り続けるならMax以上、たまに1本試すだけならPro、という目安になりそうです。

トークンを節約するプロンプト設計

消費を抑える最大のコツは、最初のプロンプトで情報を出し切ることです。Claude Designは具体的な指示が足りないと逆質問を繰り返すので、その往復だけでトークンが消えます。筆者の検証では事前に方向性・必須要素・バリエーション数を明記したため、Claude側から「依頼内容がかなり具体的なので即着手します」と宣言されて逆質問ラッシュをスキップできました。

よくある質問

まとめ

3件の検証でわかったことを3点に整理します。

• Claude Designは「数分で初稿が出る」プロトタイピングツールで、画像生成AIでもFigma代替でもない独自の立ち位置にある
• URL参照・多軸Tweaks・景表法表記の自発的挿入・日本語フォント自動選定・著作権ガードレールなど、実用レベルの機能が研究プレビュー時点で揃っている
• PNG直接出力なし・実データ連携なし・Pro枠はタイトなど制約もあり、完成品ツールではなく「議論と実装のたたき台生成器」として捉えるのが現実的

副業エンジニアの視点では、LP草案・UIプロトタイプ・スライド初稿といった「議論を前に進めるための素材」を数分で揃えられる価値が大きいツールです。最終成果物ツールではなく、思考を可視化する道具として使うと効きます。記事制作ワークフロー全体にAIをどう組み込むかはClaude記事制作ワークフローの全記録にまとめています。

外部情報としては、Anthropic公式のClaude Design発表記事、Opus 4.7の詳細を扱ったAnthropic APIドキュメント、Proプランでのクォータ消費実測を含むPCWorldの検証レポートが参考になります。

ムラサキ

Handoff to Claude Codeで実装まで通すフローはClaude Design→Code｜handoffで既存プロジェクトに統合にまとめました。既存Reactプロジェクトへの統合記録です。

SE歴20年・Claude Max 5x契約の筆者が、Handoff to Claude Codeを使って既存リポジトリに統合した一次体験です。結論から言うと、Design→Codeの受け渡しはURL経由のfetch方式で、Design枠は消費せずCode枠+3%のみ、実装完了まで約1時間、437テスト全パス・Viteビルド成功までたどり着きました。

ムラサキ

Design単体の検証は昨日済ませたので、今回は「本番寄りの既存プロジェクトに統合する」実運用フェーズの記録です。

Handoff to Claude Codeの正体

Claude DesignのExportメニューにある「Handoff to Claude Code」は、Design側で生成したUIモックをClaude Codeに引き渡すための公式機能です。どういう仕組みで動いているのかを実測しました。

「Send to local coding agent」ダイアログの中身

Designプロジェクト画面の右上「Export」→「Handoff to Claude Code…」を選ぶと、「Send to local coding agent」というダイアログが開きます。ダイアログの中身は次の3要素です。

• Claude Code用の指示コマンド（コード風の枠に表示される）
• Copy commandボタン（指示文をクリップボードにコピー）
• Give the agent more detailの自由記述欄（追加指示を書ける）

オプションとして「Download zip instead」のチェックボックスもありました。URLが何らかの理由で使えない場合に、ローカルzipダウンロードに切り替えてClaude Codeのチャットに手動で投入する代替手段です。

APIエンドポイント経由のURLフェッチ方式

表示される指示コマンドは次のような形です。

Fetch this design file, read its readme, and implement the relevant
aspects of the design.
https://api.anthropic.com/v1/design/h/<project-id>?open_file=Matches+Screen.html
Implement: Matches Screen.html

Anthropic側のAPIエンドポイントにDesignの成果物がホストされ、Claude Code側がそのURLをfetchして読み込む設計です。Claude Codeのログを見ると、実際にはfetch後にgzip圧縮ファイルが保存され、それを解凍して読み込む流れになっていました。

この方式の利点は、Design側がCode側のファイルシステムを直接操作しないこと。受け渡しは読み取り専用の配信で、ローカルに何を書くかはすべてClaude Code側の判断に委ねられます。

追加指示欄で統合方針を伝えられる

デフォルトの指示コマンドだけでは「このデザインを実装して」という漠然とした依頼にしかなりません。今回は自由記述欄に以下の統合方針を入力しました。

• 対象プロジェクト（既存のReact + Vite + Tailwind）と置換対象ファイルの明示
• 作業ブランチ名
• 既存自前コンポーネントを優先使用する方針
• モックデータは破棄して既存のAPI関数に接続する方針
• 作業フロー（CLAUDE.md/BUGS.mdを読む→既存機能を把握→計画提示→承認後に実装）

この欄に既存資産の情報を詰め込むと、後述の通りClaude Codeが計画段階で既存コードと整合性を取るための下調べをしてくれます。

ターミナルで受け取る（CLI経由の実行）

Handoffの受け取り方はいくつか選べますが、今回はClaude Code CLI経由で実行しました。

Copy commandで取得してClaude Codeに貼り付ける

流れはシンプルです。

1. ダイアログのCopy commandボタンをクリック
2. ターミナルでプロジェクトディレクトリに移動
3. claude でClaude Code CLIを起動
4. クリップボードの指示コマンドを貼り付けてEnter

これだけで、Claude CodeがURLをfetchして実装準備に入ります。Mac版Claude Code、VSCode拡張、JetBrainsプラグインなど他のインターフェースでも同じコマンドを貼り付ければ動くはずです。

Design枠は消費しない（Code枠のみ課金）

今回の作業前後でClaude Designの週次枠を実測した結果、Handoff後もDesign枠の消費はゼロでした。Claude Codeが fetch する先は静的配信のURLなので、Design側の生成処理は走っていないと理解できます。

代わりにClaude Code側の5時間セッション枠が25%から28%へ3ポイント増加。Max 5xプラン実測で、1本の本格的な統合作業がCode枠の+3%で済む計算になります。Claude CodeのOpus 4.7・Sonnet 4.6・Haiku 4.5のコスト感を踏まえると、個人開発レベルなら十分現実的な消費ペースです。

Claude Codeが自発的にやったこと

指示を投げたあとのClaude Codeの挙動が想像以上に賢く、Handoffの価値の大半はここにあると感じました。

Design成果物fetchと既存コード探索を並行実行

実行開始直後、Claude Codeは「デザインファイル取得と既存コードの探索を並行実施」と宣言し、実際に両方を同時に走らせました。

• 「デザインファイルを取得する」→「gzip圧縮ファイルが保存された。解凍して読む」→「デザインファイル完全に取得できた」
• その間に既存プロジェクトのCLAUDE.md・BUGS.md・既存ページ・関連コンポーネントを探索

統合型の実装では、新規資産（Design出力）と既存資産（プロジェクトのコード）の両方を把握しないと計画が立てられません。Claude Codeはこの並行実行を自動で判断していました。

テーマ衝突を検出して逆質問

取得完了後、Claude Codeは「設計に入る前に重要な決定を確認」として、AskUserQuestionツールで逆質問を投げてきました。

デザインはウォームクリーム（#FAF7EF）の明るいテーマですが、既存プロジェクトはネイビー（#0a1628）のダークテーマです。対象ページをどちらに合わせますか？

選択肢として「デザイン通り（明るいクリーム）」「ダークテーマに合わせる」「他の内容を入力」の3択が提示されます。さらに各選択肢には、右カラムに「背景: #FAF7EF（ウォームクリーム）カード: #FFFFFF + 薄影 テキスト: #2B2B2B アクセント: #E5A621（ゴールド）→ デザイン通りの見た目になる → 他ページはダークテーマのまま」という帰結説明が付いていました。

指示されていない判断ポイントを自発的に発見して、帰結まで提示して確認を取る挙動です。Design→Code統合の実運用では、この「既存環境との衝突検出」が一番重要なステップだと実感しました。

計画書に既存技術的癖の回避策まで含めてきた

テーマ判断（今回は「デザイン通り」を選択）のあと、Claude Codeは詳細な計画書を提示してきました。

計画書の構成は次の通りです。

• Context（作業の前提）
• 対象ファイル（4ファイルを明示）
• カラーパレット（Design出力から抽出した7色）
• 重要テクニック
• メインコンポーネントの新構造（ASCIIアートで描画）
• ページ側の変更点
• 実装手順
• 再利用する既存資産
• 検証方法

特に「重要テクニック」の項目が秀逸で、次のように書かれていました。

Tailwindのbg-white等はindex.cssの!importantでダーク上書きされる

インラインスタイル（style={{ background: '#FAF7EF' }}）を使えば!importantの影響を受けない

既存ロジック（API関数・カスタムフック・フィルター関数）はすべて維持

プロジェクトの既存CSSが持つ「!importantでTailwindを上書きする」という技術的癖を読み取り、それを回避する具体的な戦略まで計画段階で組み込んでいます。追加指示に含めていなかった内容を、既存コードを読んで自律的に発見した挙動です。

実装結果の実測

計画を承認してから実装完了までは、逆質問の往復を含めて約1時間弱でした。

変更ファイル4つ・437テスト全パス・ビルド成功

最終的な変更内容は次の通りです。

• メインコンポーネント：デザイン通りに全面再設計（トレーナー情報帯・2カラム中央揃え本体・フッター帯・ゴールドグラデーションのリクエストボタン）
• ページ側：ページ背景#FAF7EFをインラインスタイルで設定してダークテーマ上書きを回避、countバッジ付きタブフィルター、アイコンボックス付きセクションヘッダー
• index.html：Zen Maru Gothic / M PLUS Rounded 1cフォントを追加
• テストファイル：クラス名ベースassertionを削除・更新

• npm run test:runの結果：437 passed / 0 failed
• Viteプロダクションビルド：成功
• コミットまで自動で完了

Tailwindクラス名に依存した既存テストをClaude Codeが自律的に書き換えた点が重要です。デザイン変更でTailwindクラスが変わるとテストが壊れやすい問題を先回りして対処しています。

クォータ消費はCode枠+3%のみ

Design→Codeの受け渡しは静的ファイルのfetchなので、Design側の生成処理は走りません。Code側の実装作業だけが課金対象になる構造です。大規模なリファクタや新機能開発ではなく既存画面の置き換えだったため、Code枠の消費も軽く済みました。

見た目の再現度と既存機能の両立

実装後の対象画面と、他ページの画面を並べると、テーマの封じ込めが機能していることが確認できます。

対象ページ側はDesign出力通りのクリーム色背景とカード、ゴールド系アクセント、丸ゴシック系フォント。既存ロジック（方向フィルター、表示用バッジ、情報帯など）も維持されています。Design出力には無かった既存機能も、既存コードから読み取って再実装してくれた形です。

一方の他ページ側は元のダークネイビーテーマをそのまま維持。インラインスタイルでダークテーマ上書きを封じ込めた戦略が、他ページに一切漏れていません。追加指示に「他ページには影響させるな」と書いていなかったにもかかわらず、Claude Codeが計画段階でこの分離を設計していたことになります。

Design→Codeフローで見えた注意点

3件のDesign検証に続けて今回の統合作業を実行して、実運用で押さえておきたいポイントが見えてきました。

テーマ衝突は必ず起きる想定で計画する

Design側は配色・フォント・余白を独立に設計するため、既存プロジェクトと100%一致するケースはほぼありません。AskUserQuestionで逆質問が来るパターンを想定し、判断材料（既存テーマの色コード・フォント・CSS設計思想）を事前に整理しておくとスムーズです。今回は「index.cssで!important上書き」という癖が事前に整理されていたからこそ、Claude Codeが回避策を提示できた側面もあります。

既存自前コンポーネントの扱いは追加指示で明示する

追加指示欄で「既存自前コンポーネントを再利用する」「Design出力に同等コンポーネントが含まれていても既存版を優先」と明示したことで、Claude Codeは計画段階で再利用リストを作り、Design出力の一部をそのまま活かしつつ既存コンポーネントを維持する判断をしました。明示がなければDesign出力をそっくりそのまま置き換える形になっていた可能性があります。

言語・型設定は追加指示で回避する

Design出力はJavaScriptで来ましたが、プロジェクトによってはTypeScript化を自動で試みる挙動もありうるため、追加指示欄に「JavaScript (.jsx)を維持。TypeScript化しない。」と明記しておくのが安全です。今回はこの一文があったため、Claude Codeは一切TS化を試みず既存のJS構成を尊重しました。

mainブランチには直接適用しない（必ずフィーチャーブランチ）

Handoffの挙動は予測不能な部分があり、最初の1手で既存のmainが壊れるリスクがあります。今回はフィーチャーブランチで作業し、mainへのマージは後日の追加検証フェーズに持ち越しました。Claude Codeを使った個人開発の運用ノウハウはClaude Codeで個人サービスを作った正直な話にまとめてあります。

よくある質問

まとめ

3点に集約します。

• Handoff to Claude CodeはAPI経由のURLフェッチ方式で、DesignとCodeのファイルシステムを直接繋がない安全な設計
• Design枠は消費せず、Code枠のみ+3%で本格的な既存プロジェクト統合が完了した実測値
• テーマ衝突・既存コード癖・テスト更新などの「実運用で必要な判断」を、Claude Codeが計画段階で自発的に拾ってくれる

Design単体の検証は前回の記事で完結しましたが、本当の価値はDesign→Code handoffによる「初稿生成→実装まで一本化される体験」にあると実感しました。次はClaude Code v2.1.114時代の他の新機能も/powerup入門あたりと繋げて試していく予定です。

外部情報としては、Anthropic公式のClaude Design発表記事{target=”_blank” rel=”noopener noreferrer”}、Opus 4.7の仕様を整理したAnthropic APIドキュメント{target=”_blank” rel=”noopener noreferrer”}、Claude Code公式ドキュメント{target=”_blank” rel=”noopener noreferrer”}が参考になります。

ムラサキ

main/masterへのマージは追加検証フェーズに回します。Claude Codeで自作サービスをどこまで自動化できるかは、別記事でまた検証予定です。

結論から書く。料金は据え置き（入力$5/M・出力$25/M）で、高難度コーディングと長時間タスクの一貫性が明確に強化された。Opus 4.6比でベンチマーク全般が向上し、導入コストは変わらない。ただしClaude CodeでOpusを多用するとレート上限に到達しやすいため、作業フェーズに応じたSonnet/Opusの使い分けが現実的だ。

ムラサキ

この記事を書いている4月17日時点で、チャット版Claudeは既にOpus 4.7に切り替わっています。Claude Code側はトークン管理の観点からSonnet 4.6中心の運用を継続しています。

Claude Opus 4.7で何が変わったのか

Opus 4.7の位置づけを一次情報で確認する。Anthropic公式発表と公式ドキュメントの仕様表を照合しながら、Opus 4.6からの差分を押さえる。

発表内容と主要アップデートの概要

Anthropic公式発表（Introducing Claude Opus 4.7）によると、強化ポイントは4点に集約される。

• 高難度コーディング：従来は緻密な監督が必要だった難しい作業も、安心して任せられるレベルに到達
• 長時間タスクの一貫性：数時間におよぶ実行でも計画どおりに進み、出力の自己検証まで行う
• 視覚認識の高解像度化：画像をより高い解像度で扱い、技術図面や化学構造の読み取り精度が向上
• 料金据え置き：入力$5/Mトークン、出力$25/MトークンでOpus 4.6と同額

APIモデルIDはclaude-opus-4-7。Claude API・Amazon Bedrock・Google Cloud Vertex AI・Microsoft Foundryで同日提供開始となった。

Claude 4.6系からの進化ポイント

Claude 4.6系（Opus 4.6・Sonnet 4.6）とのスペック比較は次のとおり。公式ドキュメント（Models overview）から抜粋した。

注目すべきはOpus 4.7の知識カットオフが2026年1月と、Sonnet 4.6（2025年8月）より約5ヶ月新しい点だ。AIの最新動向や2026年の技術トレンドを扱う場面では、この差が調査の裏取り精度に直結する。

Opus 4.7はExtended thinking（長時間思考）を持たない代わりに、Adaptive thinking（タスクに応じた思考時間の自動調整）を備える。ユーザーが思考時間を明示指定しなくても、モデル側が難易度を判断して思考リソースを配分する設計だ。

Anthropic公式が示す位置づけ

公式ドキュメントは「複雑な推論とエージェント的コーディングに最も適した、一般提供中で最も高性能なモデル」とOpus 4.7を位置づけている。重要なのは「一般提供中（generally available）」という限定詞だ。

AnthropicはMythos Previewの一般公開に向けた段階的な安全性検証の第一弾としてOpus 4.7をリリースしたと説明している。サイバーセキュリティ関連の高リスク要求を自動検知・ブロックする安全機構が組み込まれた点も4.7の特徴だ。

コンテキスト性能の強化と実務インパクト

ここでの「コンテキスト性能」は、コンテキストウィンドウのサイズではなく長文コンテキストを扱う際の一貫性・安定性を指す。ウィンドウサイズ自体は1Mトークンで4.6から変わっていない。

長文処理・ドキュメント解析の精度向上

公式発表に掲載された早期アクセステスターのコメントで注目すべきは、研究エージェント用途での評価だ。「6モジュール横断で総合スコアが同率1位、長文コンテキストでの一貫性はテストしたどのモデルより安定」という評価がApplied AI社から出ている。

筆者自身も、Opus 4.6時代に大量の既存記事を読み込ませて内部リンク候補を洗い出す処理で、指示の取りこぼしを経験したことがある。発生位置が文章のどこかまでは計測していないが、長いインプットを扱う処理では取りこぼしが起きうるという認識だ。Opus 4.7でこの取りこぼしがどう変わるかは、今後の運用で比較していく。

コード全体を横断した理解力の違い

CursorのCEOマイケル・トルーエル氏は、社内ベンチマーク「CursorBench」でOpus 4.7が70%を突破（Opus 4.6は58%）と公開している。12%の差は、単一ファイル編集では見えにくく、複数ファイルにまたがる依存関係の把握で現れる差だ。

副業開発でこの恩恵が出るのは、モノレポ構成の複数サイト横断修正・WordPressテーマ改修と管理スクリプトの連動修正といった場面。単機能のスクリプトや1ファイル内のバグ修正なら、Sonnet 4.6で十分捌ける範疇だ。

副業開発で効く具体的なシーン

筆者がOpus系の「長文一貫性」を必要とする場面を具体的に挙げる。

推論性能アップがもたらす開発体験の変化

推論性能の向上は、ベンチマークの数字より使用者が感じる体験の変化として現れる。公式発表の早期アクセステスターコメントから傾向を拾う。

この安定性を、完了条件を満たすまでの自走として引き出すのが/goalだ。条件を満たすまでAIを走らせる仕組みで、実際の動作フローと前提条件を解説している。 ──────────────────────────── 備考 ──────────────────────────── – 本文修正（A〜F）: 該当する重大な陳腐化・矛盾は確認されませんでした。/goalは既存記事と異なる新規キーワード（完了駆動の自走）のため、カニバリゼーションリスクは低と判断。 – 種別G（アフィリエイトリンク）: 今回は書籍候補なし（ヒアリングQ5）のため提案なし。 – 内部リンクは1既存記事につき最大1本・計4本。すべてstructure_index.mdでH2見出しの完全一致を確認済み。“`

複雑なタスク分解と計画立案の精度

公式発表冒頭の「計画フェーズで自分の論理的欠陥を捕捉する」という記述は、エージェント運用で実務的な意味を持つ。プラン→実行→検証のループで、プランの段階でミスを見つけるか実行後に発覚するかは、消費トークンに直結するからだ。

Hex社のCTOは「low-effortのOpus 4.7がmedium-effortのOpus 4.6とほぼ同等」と評価している。同じ精度を出すための思考リソースが減ったということは、Adaptive thinkingのタスク難易度判定が効率化されたと読める。

エージェント的ワークフローでの安定性

Notion AI LeadのSarah Sachs氏は、「Opus 4.6比で14%の成果向上かつ消費トークンは減少、ツールエラーが3分の1」と公開している。ツールコール失敗後のリカバリ能力も強化されており、従来はそこで詰まっていたワークフローが完走するようになった。

副業開発の文脈でこれが刺さるのは、RSS収集→AI評価→Slack通知→記事生成→WordPress投稿のような多段パイプライン構築時だ。途中1ステップで止まると復旧コストが跳ね上がる構造なので、エラー耐性の差はそのまま運用負荷に直結する。

既存モデル（Sonnet/Haiku）との使い分け

Claude 4.7世代はOpusのみの提供で、Sonnet・Haikuは4.6/4.5が現行最新だ。つまり使い分けの土台は「Opus 4.7 × Sonnet 4.6 × Haiku 4.5」の3モデル構成になる。

• Haiku 4.5：$1/$5。定型的な整形・分類・短文生成。200kコンテキスト
• Sonnet 4.6：$3/$15。日常的なコーディング・記事執筆・Extended thinking対応
• Opus 4.7：$5/$25。高難度コーディング・長文横断推論・エージェント運用の要所

価格差は小さく見えるが、出力はOpusがSonnetの約1.67倍。副業開発で数万トークン単位の処理を繰り返すと、月末請求で効いてくる差だ。

副業・個人開発で活かすユースケース

Opus 4.7を副業開発で活かすには、コストに見合う場面を絞る。筆者が実践しているフローから3つ紹介する。

SEOコンテンツ制作の品質向上

2026年4月17日にはOpus 4.7を基盤とするClaude Designがリリースされ、プロトタイプ・LP・スライドの初稿生成に活用できるようになった。実測の挙動と使いどころはClaude DesignでLPを生成した実測レポートにまとめている。

記事制作のフェーズによってSonnetとOpusを使い分けている。パイプライン経由で新規ネタを見つけて検討内容の概要をまとめるまではSonnet（API）。骨子作成から本文執筆は非API（チャット版Claude）でOpusを使う。筆者発信のネタで記事を作成する場合は、最初からOpusで進めるフローだ。

このフローで効くのが、Opus 4.7の長文一貫性強化だ。骨子作成から本文執筆までを1つのチャットで進めると、文脈が数万トークンに達する。後半で骨子の指示が効かなくなると、本文の構造がブレる。Opus 4.7でこの部分がどう安定するかは今後の運用で見ていく。

詳しいワークフローはClaude記事制作ワークフローの全記録にまとめている。

Claude Codeを使った自動化パイプライン

Claude CodeはMax 5xプランでもセッション単位のレート制限がかかる。筆者はPro時代に5時間上限を3回踏んだ経験があり、Max移行後もClaude Code上ではSonnet中心で運用している。Opus 4.7リリース後もこの方針は変わらない。

ただし、モノレポ複数サイト横断の大規模リファクタや新規機能のアーキテクチャ設計フェーズでは、レート制限を承知の上でOpus 4.7を一時的に使う判断はあり得る。Claude Code上で起きた困りどころはClaude Code個人開発の正直な話で詳述している。

リサーチ・企画・分析の時短術

Web検索＋長文ドキュメント要約＋競合分析を1チャットで完結させるリサーチ業務は、Opus 4.7との相性が良い。4.7の知識カットオフが2026年1月まで伸びたため、2025年末〜2026年初頭の技術動向を追う際、Web検索に頼る頻度が下がる。これは副業開発の企画フェーズで、裏取り工数そのものを削る効果を持つ。

コストとモデル選択の最適解

個人が無理なくOpus 4.7を使うには、消費ペースの感覚値を持っておく必要がある。

モデル選択と並行して効くのが、トークン消費の少ない外部記憶を持たせる設計だ。トークン消費ゼロで知識を蓄積するナレッジベース構築例では、MCP不使用・hookベースでの実装パターンを紹介している。

この料金感はOpus 4.7時点のもので、後継のOpus 4.8は同じ$5/$25のまま正確さとFast modeのコストが改善している。最新版での価格据え置きでの変更点と副業での使い方を踏まえると、乗り換え判断がはっきりする。

Opus 4.7の料金感と消費スピード

入力$5/M・出力$25/M。日本円換算で、入力1Mトークンが約760円・出力1Mトークンが約3,800円（2026年4月17日時点の為替約152円/ドル換算。レートは変動する）。

Claude Max 5xプラン（月200ドル・約30,400円）は、従量課金での予想請求額がこの金額を超える使い方をする場合に、固定料金でレート上限と引き換えに安定利用できる選択肢だ（Anthropic公式料金ページ）。

用途別にSonnet・Opusを使い分ける

筆者の実運用では、作業フェーズでSonnetとOpusを明確に切り分けている。

ポイントは「API経由で自動処理する工程はSonnet、人間が介在しながらじっくり作る工程はOpus」という分け方だ。自動化処理はコストが積み上がりやすいのでSonnetで抑え、人間が一緒に考えるフェーズは品質を優先してOpusを選ぶ。

個人が無理なく使うための運用ルール

Claude Code Maxプランなら月額固定でレート制限と引き換えに使える。API直接利用なら従量課金で制御できる。筆者はコスト確認をClaudeの設定画面から使用料を見る形で行っている。複雑なコマンド運用を入れずに、ダッシュボードで月次の消費を把握する方法だ。

個人の副業開発で重要なのは、自分が続けられる最もシンプルな方法を選ぶこと。高度な追跡ツールを導入しても運用できなければ意味がない。

ただしモデル性能が上がってもプロンプト側の肥大化が原因の破綻は解決しない。888行プロンプトで起きた破綻事例と設計原則も併せて押さえておきたい。

モデルを正しく振り分けるだけでなく、Prompt Cacheやコンテキスト管理まで踏み込めば削減幅はさらに広がります。実測値ベースの手順は3層スタック実践でコストを半減させる方法にまとめました。

個人運用のノウハウが固まったあと、社内展開を考えるならChatGPT・Claude・Geminiの開発業務向けプラン選定ガイドで3社のエンタープライズ構造を比較しておくと、提案の解像度が上がる。

まとめ：いつOpus 4.7に切り替えるべきか

なお本記事はOpus 4.7世代での使い分け基準をまとめたもので、2026年5月28日に後継のOpus 4.8が公開された。料金据え置きでの性能向上やeffort制御の追加といった最新の変更点は、価格据え置きで何が変わったかの整理で確認できる。

Opus 4.7への切り替え判断は、現在のモデル利用状況によって大きく分かれる。

乗り換え推奨ケースと様子見ケース

推奨ケース

様子見ケース

今日から試せる導入ステップ

Opus 4.7を試す最小コストのルートはチャット版（Claude.ai）だ。Pro以上のプランならモデル選択でOpus 4.7が選べる。API経由で試したい場合は、既存コードのモデルIDをclaude-opus-4-7に差し替えるだけで済む。

まず1つ、自分が「4.6で詰まった」タスクを手元で覚えているはずだ。そのタスクを4.7で再実行して、解けるか・消費トークンが減ったかを比較する。これが一番確実な評価方法になる。

よくある質問

まとめ

Claude Opus 4.7は「料金据え置きで性能向上」という副業開発者にとって歓迎すべきリリースだ。切り替え判断は自分の作業フェーズとコスト感から決めればよい。筆者のようにパイプライン経由はSonnet・手動作業はOpusという分け方は、一つの実運用例として参考にしてほしい。

4.6と4.7の体感差を正確に知るには、自分が4.6で詰まったタスクで比較検証するのが一番早い。