AIエージェントの仕組み|モデルとハーネスで選ぶ判断軸
「AIエージェントの仕組みを理解して、自社にどのツールを入れるべきかを判断したい」と考える中小企業経営者は増えています。私はClaude Code・Cursor・Codex・Cline・Windsurf・Gemini CLIなど主要なAIエージェントツールを実務で使い比べてきましたが、選定を間違えるとコストだけがかかって生産性が上がらない結果になります。本記事では、AIエージェントの構造を「モデル」と「ハーネス」の2層で捉えたうえで、中小企業がツールを選ぶ判断軸を私の選定経験から解説します。
AIエージェントの仕組みは「モデル × ハーネス」で決まる
AIエージェントの性能を理解するうえで一番大事なのは、「中身のモデル(=エンジン)」と「ハーネス(=躯体・制御系)」を分けて考えることです。同じClaudeでも、Claude.aiのチャットとClaude Codeでは挙動がまったく違います。理由は単純で、ハーネスの設計が違うからです。
モデル(エンジン)とは何か
モデルは、Anthropic Claude Opus 4.6・OpenAI GPT-5系・Google Geminiといった大規模言語モデルそのものを指します。コンテキストをどれだけ持てるか、長文を読んでも精度が落ちないか、コーディングや推論にどれだけ強いかなど、AIの「素の能力」を決める部分です。私がClaude CodeのMaxプランに切り替えた最大の理由は、Opus 4.6に膨大なコンテキストを読ませても精度が崩れないことを実務で確認したからでした。
ハーネス(躯体・制御系)とは何か
ハーネスは、モデルを実際の業務で動かすための「外側の仕組み」です。ファイル操作・シェル実行・ブラウザ操作・MCP連携・ツール呼び出し・Skills(再利用可能なワークフロー定義)・権限制御・Hooks(自動検閲)などが含まれます。レースカーで例えるなら、エンジン単体を渡されても勝てないのと同じで、車体・サスペンション・制御系がそろってはじめてゴールにたどり着けます。
私自身、Claude Codeを「強力なエンジンに、よくチューニングされた純正ボディがついた一体型」と捉えています。モデルが暴れすぎないように、CLAUDE.md・Skills・MCP・Hooksなどの制御レイヤーが整備されていることが本質的な強みです。
同じモデルでもハーネスが違えば別物になる
たとえばClaude Opus 4.6は、Anthropic純正のClaude CodeでもCursorでもClineでも同じモデルとして使えます。それでも、同じスキルを使わせたときの挙動はClaude Codeのほうがスムーズです。これはハーネスの完成度の差で、エンジンが同じでも躯体が違えば結果は変わるという典型例です。

主要AIエージェントの構造を比較する
私が実務で使い比べてきた主要ツールを、モデルとハーネスの組み合わせで整理します。「モデル + ハーネス」の整合性が高いほど、業務での再現性が上がるというのが私の結論です。
Anthropic Claude Code(純正)
- モデル: Claude Opus 4.6 / Sonnet 4.6
- ハーネス: CLI主体。Skills・MCP・Hooks・Subagents・/loop・/scheduleなど、業務全般の自動化に必要な構成要素が純正で揃う
- 強み: モデル開発元が同じ会社のため、新機能の追従が早く、思考予算・コンテキスト管理・エージェントモードなどの細部までモデル側と整合している
私がメイン開発ツールをClaude Codeに据えている理由は、コーディング・記事執筆・調査・ファイル整理・提案書作成まで、業務のほぼ全範囲を1つのハーネスで回せるからです。「複数モデル間でコンテキストを受け渡すのが面倒」という実務上の不満を、純正ハーネスが解消してくれました。
OpenAI Codex / ChatGPT
- モデル: GPT-5系
- ハーネス: ChatGPT Plus($20/月)に含まれるCodex。長時間稼働・大量コンテキストでも精度が落ちにくい
- 強み: 単純作業・リファクタリング・ディープリサーチに強い。Claude Codeのトークンを節約したいときの逃がし先として優秀
私はClaude CodeのMaxプランの上限に達したときや、調査・マークダウン整形などの単純作業をCodexに流しています。Skills的な概念はClaude Code側に軍配が上がりますが、サブ用途には十分です。
Cursor
- モデル: 複数モデル(Claude / GPT / Gemini / Composer 2など)を切り替え可能
- ハーネス: IDE主体。GUIで直感的に操作でき、IDE完成度は最も高い
- 強み: 非エンジニアでも入りやすい。複数モデルの得意不得意に合わせて使い分けたい場面で有利
CursorもMCPやルールファイル(Skills相当)に対応していますが、同じ素材を渡してもClaude Codeほどスムーズに挙動しないと感じる場面があります。私はCursor上のターミナルからClaude Codeを呼び出す併用スタイルに落ち着いています。
Cline / Windsurf / Replit / Bolt / v0
- Cline: 1年前にCursor拡張で使用。Claude Code登場後は、業務全般の自動化基盤としては力不足になり乗り換え
- Windsurf(Antigravity): プランモードなどコンセプトは面白いが、IDEとしての安定性はCursorに劣る
- Replit / Bolt / v0: 全自動でアプリを作るタイプ。コードレビューを前提にした受託開発では、Git管理や挙動の見通しの面で業務では不採用
Gemini(画像・デザイン用途)
- モデル: Gemini 3.1系
- ハーネス: 画像生成・デザイン素材生成に強い
- 強み: 私の業務では画像生成はGemini一択。Claude Codeのトークンを温存しつつ、画像・グラフィックを別エンジンで処理する分業体制を組んでいます
中小企業がAIエージェントを選ぶときの4つの判断軸
ここからが本記事の核心です。中小企業がツールを選ぶときは、「機能比較表」ではなく、ハーネスの設計思想で見るべきだと私は考えています。具体的な判断軸は次の4つです。
判断軸1: 大量のコンテキストを読ませても精度が落ちないか
中小企業が業務でAIエージェントを使う場合、ほぼ確実に「自社の業務マニュアル」「過去のクライアント記録」「商品データ」など、固有のコンテキストを大量に読ませる場面が出てきます。ここでモデルの精度が落ちると、いくら自動化しても出力が信用できなくなります。
私の体感では、Opus 4.6は10万トークン以上を読ませても安定して回答してくれます。Codexも長時間稼働で大量トークンに耐えます。一方、コンテキストを増やすほど挙動が荒れるツールもあるので、社内データを丸ごと食わせる前提で導入するなら、ここを最優先にすべきです。
判断軸2: 自社業務をハーネスに落とし込めるか(Skillsとルールファイルの自由度)
ハーネスの自由度は、繰り返し業務を自動化できるかどうかを決めます。Claude CodeのSkillsやCLAUDE.mdのようなルールファイルが充実しているほど、「自社の手順を書いて再利用する」運用がやりやすくなります。
私が実際にSkill化して効果が大きかった業務には、SEO記事執筆・提案書作成・画像生成・PDF出力などがあります。SEO記事1本(約5,000文字)が30〜40分から4〜5分まで圧縮できた最大の理由は、業務手順をSkillに書き出してハーネス側に持たせたからです。一方、「クライアントへの返信」のように毎回温度感を変える業務はSkill化しないほうが速い、というメリハリも実務で見えてきます。
判断軸3: 既存システムとMCPで繋がるか
MCPは、AIエージェントから外部システム(会計freee・カレンダー・データベース・社内ツールなど)を操作するための共通プロトコルです。中小企業視点では「自社で使っているクラウドサービスがMCPで繋がるか」が、AIエージェント導入の費用対効果を大きく左右します。
私の運用では、MicroCMS・Supabase・freee・Google系などをMCP経由で接続しています。freeeは2026年3月に公式MCPがリリースされ、Claude Code Pluginとしても配布されるようになりました。一方で、使っていないMCPを許可状態のまま残すと情報漏洩の口になるため、案件ごとにallow/denyを引き締めるのが基本姿勢です。MCPは「繋がれば便利だが、繋ぎっぱなしは危険」というのが正直なところです。
判断軸4: モデル開発元の純正サポートを受けられるか
これは見落とされがちですが、長期運用では非常に重要です。Anthropicが2026年4月に発表したClaude Managed Agentsのように、「モデル開発元がインフラ込みで安全な実行環境を提供する」流れが本格化しています。隔離環境・認証・権限管理を自社で整備するのは、中小企業にとって現実的ではありません。
純正のハーネスを選ぶメリットは、新機能のアップデートが最速で降ってくること、セキュリティガードレールがモデルと整合していること、そしてエンタープライズ運用に必要な仕組みが標準で揃うことです。私がClaude Codeを「業務の主軸」に置いている理由のひとつは、この純正サポートの厚みにあります。

典型的なミスマッチパターンと避け方
ここからは、中小企業がAIエージェント選定で陥りがちな失敗パターンを、私の現場感覚で挙げます。
ミスマッチ1: 「最新モデル」だけで選ぶ
「GPT-5が出たから乗り換える」「Geminiが安いから移行する」というモデル単体での選定は、ハーネスを軽視しています。モデルを切り替えるたびに、Skillsもプロンプトも再設計が必要になり、結局は社内に何も残らない事態になりがちです。
ミスマッチ2: 全自動コード生成系を業務に入れる
Replit・Bolt・v0などの「ワンクリックでアプリができる」系は、デモには強いですが、運用に乗せるとGit管理・挙動の見通し・人間レビューが効きづらく、品質が安定しません。私の業務では、自前のIDE上でAIと並走する形でしか採用していません。
ミスマッチ3: モデルを切り替えすぎる
「タスクごとに最適なモデルを切り替える」という発想は理屈としては美しいですが、コンテキストの受け渡しコストが大きく、現場では破綻します。私はOpus 4.6に統一し、本当に単純な作業だけSonnet 4.6に振る運用にしています。
ミスマッチ4: セキュリティを設計せずに導入する
AIエージェントは「何でもできる」ので、「何でもしでかす」可能性があります。私は過去に、AIが自動でrobots.txtのインデックス設定を変更してプッシュしてしまった経験があり、それ以来、案件ごとにpermissionsのdenyとHooksの監視を必ず入れています。中小企業がAIエージェントを業務に入れるなら、「制限することで本質的な価値を高める」というハーネスエンジニアリングの発想は欠かせません。
中小企業の現実的な導入順序
私が非エンジニアの経営者・担当者に推奨している順序は、シンプルです。
- ステップ1: まずCursorのIDEを使えるようになる。GUIで直感的に動かせるので学習コストが低い
- ステップ2: Claude Code拡張機能を入れて、Skills・MCPなどClaude Code特有の概念に触れる
- ステップ3: 業務で繰り返している作業を1つずつAIに代替させる。最初の1本をSkill化する
- ステップ4: 最終的に「AIにとって効率の良いワークフロー」に自社の業務を寄せていく
大事なのは、「AIに何ができるか」を一気に把握しようとしないことです。1つの業務をAIに渡してSkill化する、その経験が次の判断材料になります。ハーネスを育てる過程自体が、自社の業務理解を深める作業になっているからです。
まとめ: AIエージェントは「モデル × ハーネス × 自社業務」で評価する
AIエージェントの仕組みは、モデル単体ではなく、モデルとハーネスの組み合わせで決まります。中小企業がツールを選ぶときは、機能比較表ではなく、コンテキスト精度・Skill自由度・MCPエコシステム・純正サポートという4つの判断軸でハーネスを評価するのが現実的です。
私がClaude Codeをメインに据えているのは、Opus 4.6のコンテキスト精度と、純正ハーネスの整合性、そしてSkills・MCP・Hooksによる制御の自由度が、自社の業務と最もうまく噛み合ったからでした。同じ判断軸で自社の業務にあてはめれば、最適なツールの組み合わせは自然と見えてくるはずです。
関連する判断材料としては、エージェント型AIとチャット型AIの違い、複数ツールを組み合わせた実務構成についての記事も参考になります。
「Claude Code を自分で使いこなしたい」「自社の業務に組み込みたい」
── そんな方は、まず初回無料相談でお話ししてみませんか。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。