AI エージェント入門 — 元 Meta エンジニアが説く「オートメーションとエージェントの決定的な違い」

AI エージェント入門 — 元 Meta エンジニアが説く「オートメーションとエージェントの決定的な違い」

「AI エージェント」という言葉が溢れる2026年。しかし、本当に「エージェント」と呼べるものはどれだけあるのでしょうか。

@kgsi（こぎそ）さんのポストで紹介されていた、元 Meta ソフトウェアエンジニア Vasuman Moza 氏の「AI Agents 101」は、コードを書く前に理解すべきエージェントの本質を明快に整理しています。

“If you want to learn how to build AI Agents, read this before you write a single line of code.” （AI エージェントの構築を学びたいなら、コードを1行書く前にこれを読め）

この記事では、Vasuman 氏のガイドの要点と、エンジニアが押さえるべきポイントを解説します。

オートメーション vs エージェント — 根本的な違い

最も重要な区別は、指示（instructions） と 目標（goals） の違いです。

一言で言えば：

• オートメーション：「A が起きたら B をしろ」
• エージェント：「X を達成しろ。やり方は任せる」

この違いは単なる定義の問題ではなく、設計思想そのものに影響します。オートメーションは手順書を書く作業ですが、エージェントは「何を達成すべきか」と「何をしてはいけないか」を定義する作業です。

エージェントの3つのコアコンポーネント

Vasuman 氏によると、プロダクション品質のエージェントには3つの要素が必要です。どれか1つでも欠けると、エージェントは有用な仕事ができないか、解決するより多くの問題を生み出します。

1. Perception（知覚）— エージェントが世界を見る方法

エージェントが情報を取得する仕組みです。通常は API、データベース、ドキュメントストアの組み合わせで構成されます。

[API] ──┐
[DB]  ──┼──▶ エージェントの知覚層
[Docs] ─┘

ここで重要なのは、エージェントに必要な情報だけを渡すことです。全てのデータを流し込むと、ノイズが増えて判断精度が下がります。

2. Decision Logic（判断ロジック）— エージェントが次に何をするかを選ぶ方法

プロダクション環境のエージェントは、全ての判断に LLM を使うわけではありません。

• 定型的なケース：構造化された決定木（decision tree）で処理
• 曖昧なケース：LLM を呼び出して判断

この使い分けが、コスト効率と信頼性の両立を可能にします。

3. Action Interface（行動インターフェース）— エージェントが世界に影響を与える方法

エージェントが実際に行動する仕組みです。ここには3つの原則があります。

• ログを残す：全てのアクションを記録する
• 可逆にする：可能な限り元に戻せるようにする
• 権限で制御する：パーミッションゲートを設ける

Observe → Plan → Act ループ

3つのコンポーネントは一方向のパイプラインではなく、ループを形成します。

    ┌─────────────────────────────────┐
    │                                 │
    ▼                                 │
 Observe ──▶ Plan ──▶ Act ──▶ 結果を観察
(知覚層)    (判断層)   (行動層)

1. Observe：知覚層を通じて現在の状態を観察する
2. Plan：判断ロジックで次のアクションを決める
3. Act：行動インターフェースを通じて実行する
4. 結果を観察：アクションの結果を知覚層で確認し、ループの先頭に戻る

ゴールが達成されるまで、このループが繰り返されます。

ツール設計の原則

エージェントが使う「ツール」は、呼び出し可能な関数です。設計の鉄則は 1ツール1機能。

✅ 良い設計:
  - send_email(to, subject, body)
  - query_database(sql)
  - create_calendar_event(title, time)

❌ 悪い設計:
  - do_everything(action_type, params...)

ツールの粒度が適切であれば、エージェントは状況に応じて正しいツールを選択できます。逆に、1つのツールに複数の責務を持たせると、エージェントの判断が不安定になります。

ガードレールとパーミッション

エージェントに自律性を与える以上、やってはいけないことを明確に定義する必要があります。

ガードレール（Guardrails）

エージェントが絶対に超えてはいけない境界線です。

• 禁止アクション：「データを削除してはならない」「本番環境に直接デプロイしてはならない」
• レート制限：「1分間に10件以上の API コールを行ってはならない」
• コスト上限：「1回のタスクで $X 以上の API コストを発生させてはならない」

パーミッション（Permissions）

ロールベースのアクセス制御です。エージェントの権限レベルに応じて、利用可能なツールや操作範囲を制限します。

確信度が低い場合

エージェントが判断に自信を持てない場合は、止まって人間に聞く。これが最も重要なガードレールです。

80/20 ルール — プロダクション運用の現実

Vasuman 氏が強調する、最も実践的な知見がこれです。

最良のエージェントデプロイメントは共通のパターンを持つ：80% の定型ケースを自動処理し、20% の複雑なケースは人間にルーティングする。

完全自律を目指すのではなく、人間の専門知識を本当に必要な問題に集中させることがゴールです。

受信タスク (100%)
    │
    ├── 80% 定型ケース ──▶ エージェントが自動処理
    │
    └── 20% 複雑なケース ──▶ 人間にエスカレーション
                              └── 人間は高付加価値な判断に集中

この割り切りが、エージェントの信頼性とビジネス価値の両方を最大化します。

Vasuman 氏の推奨する構築ステップ

エージェントを構築する際の実践的なステップも示されています。

1. ゴールを具体的に定義する — 曖昧な目標は曖昧な結果を生む
2. 必要な情報を全てリストアップする — エージェントが何を知る必要があるか
3. ツールを実装する — 個別の関数として独立してテスト可能に
4. 独立してテストする — 各コンポーネントを組み合わせる前に個別検証

プロンプトエンジニアリングと同様、「曖昧にしない」 ことが成功の鍵です。

Vasuman 氏について

Vasuman Moza 氏は Meta でソフトウェアエンジニアとして3年間勤務した後、2025年に AI エージェント企業 Varick Agents を創業。企業向けに実用的な AI エージェントを構築・導入するサービスを提供しています。

創業から4ヶ月で ARR $3M を達成し、クライアント企業に年間 $20M 以上のコスト削減をもたらしています。単なる AI SaaS ではなく、部門全体・企業全体の変革を掲げている点が特徴です。

まとめ

「AI エージェント」と名乗るプロダクトが氾濫する中で、Vasuman 氏のガイドは本質を見極めるためのフレームワークを提供しています。

コードを書く前に、まず「何をゴールとし、何を禁止するか」を設計する。この順番を守ることが、使い物になるエージェントと、問題を増やすだけのエージェントの分かれ目です。

参考リンク:

• こぎそ (@kgsi) のポスト
• Vasuman 氏「AI Agents 101」
• Vasuman 氏「コードを書く前に読め」
• Varick Agents 公式サイト
• Vasuman Moza LinkedIn
• AI Agents vs. Automation — AWS
• Agentic AI, explained — MIT Sloan