Notes

AIエージェントに仕事を任せる

2026-07-17
#仕組み

先日配信したOpenAIについて配信した記事、Notesに書いた内容も、私としては反応があったので嬉しかったです。ありがとうございます。今回もAIネタです。

AIとして広く一般的に認知されているのは、チャット形式のAIです。これ、友人と話をして気がつきました。だから話が噛み合わなかったのかー。いわゆる「チャッピー」は有名で、私の想像を超えて認知されていますね。

ネットでニュースを追いかけていると、よく見かけるのはAIエージェントの話です。特にMCPサーバとの連携が主なので、私も含めてまだ体験していない人は多いでしょう。

使い方の約7割は「チャット止まり」。AIエージェント化に到達したのは約1割|Yahoo!ニュース

約7割がチャット止まり、は実際にAIとして利用している人の回答なので、そもそも利用していない人も数多く居てあてにはなりません。しかし、利用者だけでも7割がチャット止まりはインパクトとしては大きい。

つまり、検索エンジンの延長か代替として使っていると想像されます。というか、私も検索エンジン代わりで使っています。

AIエージェント化が1割なのは、概念が少し難しいですし、簡単な方法である既存アプリのMCPサーバ利用も指定できるアプリが限られているのが現状だから頷けます。少なくても私が使っているアプリで対応していたのはWebブラウザくらいです。

だから、私もチャット止まりの中に入りますね。

仕事として使うなら、やはり自前でMCPサーバを開発しないと自由度も少ない。この辺のハードルがまだ高いからチャット止まりなのでしょう。

AIエージェントの定義と分類

AIエージェントという言葉は厄介です。意味はイコールで１つの筈ですが、色々なタイプに分けられているからです。チャット形式で使うAIは、AIエージェントとは区別して考えます。

2026年7月現在、私が考えるAIエージェントは次の3種類に分けられます。※今後、分類が変わる可能性があります。

作業型AIエージェント（Codex、Claude Codeなど）
ツール連携型AIエージェント（MCPを利用、ChatGPT Work、Claude Coworkなど）
独自ツール型AIエージェント（独自MCPを開発）

AIというと多岐に渡り過ぎてしまいます。AIエージェントでも同様に1種類でもありません。現時点では、入れ子の形で捉えると分かりやすいかもしれません。

AIアプリ
├─ チャット
│   └─ AIと会話
│
└─ AIエージェント
    ├─ 作業型
    │   └─ 指定した場所（Workspace）
    │       ├─ 分析
    │       ├─ 要約
    │       ├─ 修正
    │       ├─ Codex
    │       └─ Claude Code
    │
    └─ ツール連携型
        └─ MCPクライアント
            ├─ 既存MCPサーバ
            │   ├─ Gmail
            │   └─ GitHub
            │
            └─ 独自MCPサーバ
                ├─ 社内システム
                ├─ 在庫管理
                └─ 顧客管理

Gmailと連携してメールの分析や要約をさせるとしたら、ツール連携型で対応しているため既存MCPサーバと言えます。指定フォルダ内のファイルを読む、コードを修正、分析、要約であれば作業型になり、現在はCodexで十分なことも多いでしょう。

更に既存のMCPサーバを利用する仕組み以外に、独自開発のMCPサーバがある点も補足しておきます。

ai-agent-diff

独自に用意するMCPサーバなら自由度はありますが、開発する必要が出てきます。非エンジニアの私としては敷き居はグッと高くなります。

AIエージェントに判断させる

他にも”AIエージェント”と言い分ける特徴があります。 ”判断をAIに任せる”からです。

チャット形式のAIは回答しているだけですし、そもそも作業もしていません。”チャット”という通りにお喋り相手です。 AIエージェントは判断を担わせるため、”任せる”と言えます。

私の好むAPI利用も、PythonからAPIを呼び出し、自分が考えた手順をAIに実行してもらう。任せているという意味ではAIエージェントとも言えます。

hikaku-ai-agent

※Pythonと書きましたが、別にPython限定ではありません。

AIに作業を任せることは、人間でいえば別のスタッフへ指示して実行してもらうのと同じ意味合いです。私にとってAIに何かをさせることは、外部スタッフへと仕事をすることに似ています。

非エンジニアの現実的な手段

私はAPIでAIを使っています。何かしらの処理、それも私の考えた固定のロジックを実行するために、クラウドAI（OpenAIやAnthropic）にデータを渡しているだけです。処理は翻訳だったり、要約だったり、データ変換、統計・集計分析だったりします。

例えば、ニュースを検索して収集し、それをAIに渡して翻訳や要約をさせています。

logic

AIが担っているのはこの翻訳・要約とmd形式へ変換する部分です。この作業をしてもらうだけです。

api2ai

収集させているのは決めたURLだけに固定、最後のgit pushもただのコマンド実行です。

今回は出力するロジックは一定です。だから、本来のAIエージェントとは言えません。

AIエージェントは、このような一定の法則が要らないか、求める結果が不変でも良いものが適しています。例えば、翻訳だけではなく、要約もした方が良い場合、表にした方が良い場合、それを判断させるのにAIを使っているならAIエージェントです。ロジックは同じでもデータセット枠だけ固定していて、中身は固定していないような状態です。

例外はありますが、APIは”手順を教えてある仕事を任せる”。AIエージェントは”目的だけ伝えて仕事を任せる”と言えます。

非エンジニアが独自のAIエージェントを作ろうと考えた場合、MCPサーバを開発するよりも、APIを呼び出して必要な処理を組み合わせるほうが、現実的だと感じています。特に、PythonとAPIの組み合わせは、学習コストが低く、実際に動くものを早く作れるからです。

Python＋APIもバイブコーディングできる

既存のMCPサーバと連携するのは、ほぼノーコードで連携設定するだけです。但し対応しているアプリ・サービスはまだ限定的です。一方で、独自にMCPサーバを開発するのは、唯一無二のAIエージェントはできても、本格的な開発力が必要になるため、非エンジニアとしては少々現実的ではありません。

その点、私が利用しているPython+APIは、”AIに判断はさせないで決められた作業（翻訳など）をしてもらうだけ”で良いなら、仕組みを実現する手法として合っています。このPython部分も、APIの呼び出し部分も、AIに書いてもらえば済みますので実質的にはノーコードのように開発できます。

非エンジニアとして、概念や求める結果までのロジックを考えるだけで済むため、アプリ開発に取り組むことができます。

coding

私はVSCode/VSCodiumでプラグインのCLINEを使ってコードを生成しています。実際の処理は、macOSのKeychainからAPIキーを取得し、PythonからAIのAPIを呼び出しています。 APIキーをコードへ直接書かないようにしているため、処理全体は少し長くなりました。でも、私はコードを一行も書かずに実現できています。

まずは小さく始めるAI活用

AIを使った仕組みは、「プログラムコードが書けるか」ではなく「ロジックを考えられるか」があれば、非エンジニアでも実現できる時代です。

私はAIを「検索」や「チャット相手」とだけは考えていません。自分にできないことを補ってくれる外部スタッフだと思っています。だから、何をお願いして、どこまで任せるかを考えることが大切です。

決められた範囲、例えばこのフォルダの中だけ（workspace）と限定し、「○○をやらないで」と制限ルールを設けます。これをREADME.mdなどに書いておけば余計な作業を制限できたり、変更箇所を毎回CHANGELOG.mdへ出力するといったノウハウも溜まってきました。

複雑な仕組みは作ることはありません。まずは自分が毎日繰り返している小さな作業を、一つだけAIに任せてみてください。私のようにPython+APIを試してみてはいかがでしょうか。