こんにちは。CTO室の村主です。こちらはABEJAアドベントカレンダー2025の19日目の記事です。本日は「Super AI Agent と呼んでみる」というタイトルで記事を書いてみたのですが、別に何かSuper AI Agentというものを開発したわけではなく、Claude CodeやCodexなどのことをSuper AI Agent と定義してみましょう。というお話です。
5分で読めるのでお付き合いください。
なぜ定義するのか
昨今、AIエージェントがムーブメントだからか、なんでもかんでも「AIエージェント」と呼んだり、企業がマーケティング用語で「AIエージェント」と使っています。
チャットUIの裏に居るプロンプトエンジニアリングを施しただけのものから、ReActっぽい動きをするものまで様々なものが「AIエージェント」と呼ばれています。
ただ、正直Claude Codeなどを使っていると「これこそがAIエージェント..!!」と思っているのですが、「僕の思っているAIエージェント」と「世の中の広義のAIエージェント」とのギャップが大きいので、それだったらちゃんと定義してみよう。ということで定義してみることにしました。
Super AI Agentの定義
Claude CodeやCodexはコーディングだけではなく、Slackへの投稿やNotionへの読み書きなどさまざまなことが出来ます。それを紐解くと以下の3つの要素で実現していると思います。
- インターネットに接続可能なこと → 外部サービスと対話できる
- コーディングが出来ること → 新しいツールやスクリプトを即座に作れる
- シェルが実行できること → 既存のCLIツール・cURL・あらゆるコマンドを使える
先ほどのSlackやNotionへの投稿はMCPもありますが、APIが叩けるサービスであれば、インターネットに接続できてシェルが実行できるならcURLで通信することができます。
正直、この3点があればインターネット上のことは大概なんでも出来ます。この「何でもできるAIエージェント」をSuper AI Agentと定義して、世の中に量産されて欲しいと思っています。
APIが叩けるということは
システム運用が劇的に変わる
例えば何か障害が発生しました。その際に自身が管理しているインフラの各種API KeyをSuper AI Agentに渡していたとします。
上記3点を満たすSuper AI Agentは、DatadogのAPIを叩いてアラートを確認します。アラートの内容からどのAWSリソースで問題が起きているか推測し、そのサービスのCloudWatchメトリクスやログを調査しに行きます。他にもRDSで問題が発生していそうならそのメトリクスとスローログなども確認します。そして問題となるエラーメッセージを確認し、リポジトリから該当コードを特定し問題となるコードをFixさせることが可能です。
パフォーマンスの問題だとしたらX-Rayの結果を分析して「ここがボトルネックになっているので、現状のコードを踏まえるとA案、B案、C案あり、B案がオススメですがどうしますか？」と提案までしてくれます。
これらはAWSやDatadogだけではなくAzureやGCP、New RelicやSentryなども同様です。
現時点ではAPI Key利用後に無効化することを推奨しますが、これらのことは既に簡単に実現されています。Keyの漏洩と暴走を軽減できれば超現実的な用途になります。
引き継ぎが劇的に楽になる
個人的に最も恩恵を感じているのが引き継ぎです。
従来の引き継ぎ
- ドキュメントを読み込む（古い・不完全・量が膨大なことが多い）
- 先輩に聞く（忙しい・退職済みのことも）
- 障害が起きてから「あ、これか」と学ぶ
- 全体像を把握するまでに数週間〜数ヶ月かかる
Super AI Agentがいる引き継ぎ
- 「このサービスの構成を教えて」→ API経由でインフラ構成を取得・図示
- 「過去の障害パターンは？」→ Datadog/PagerDutyから履歴を取得・分析
- 「このエラー何？」→ ログ・コード・設計意図まで横断調査して説明
- 「ここ直して」→ 調査から実装まで一気通貫で対応
引き継ぎ間もないサービスでも、Super AI Agentがいれば調査をして問題の箇所まで特定し、提案から実装までしてくれます。実装を任せるかはチーム次第で良いと思いますが、いままでよりはるかに状況を把握しやすくなります。
つまり、Super AI Agentは「最強のオンボーディング・バディ」になり得るのです。
その他のユースケース
APIが提供されているSaaSは世の中に数多くあるので、上記のようにAPIを叩いて状況を見て分析して、結果と提案、実行を可能にします。単純なSaaSだと自分で操作するか、よくあるAIエージェント系のサービスを使った方が早いと思いますが、複雑なSaaSやシステムなどは理解するのに時間がかかるのでSuper AI Agentはもってこいだと思います。例えばSalesforceとか良いかもしれません。
もちろんMCPでも良いのですが、MCPを作るか提供してくれているサービスしか接続できないですし、APIであれば比較的世の中のサービスが提供してくれているので現時点ではAPIの方が優勢かなぁと思います。トークン消費面も踏まえて。
リスクと今後の課題
現時点ではAPI Keyの管理にリスクがあります。今後の課題として以下が挙げられます：
- 権限の最小化：まずはReadOnlyから始める
- 監査ログの確保：誰が（何が）いつAPIを叩いたか記録する
- サンドボックス環境での検証：本番環境に影響を与えない形で試す
これらが整備されれば、より安心してSuper AI Agentに任せられる範囲が広がるでしょう。
最後に
「AIエージェント」という言葉が氾濫している今、インターネット接続・コーディング・シェル実行の3要素を持つものを「Super AI Agent」と呼ぶことで、議論の解像度が上がると考えています。
APIが叩ける＝何でもできる。この認識がエンジニアの働き方を大きく変えます。
特に引き継ぎのような「暗黙知の塊」だった領域が、Super AI Agentによって「APIで取得可能な情報の組み合わせ」に変わる。これは本当に大きな変化だと思います。
「Super」がまだしっくりこないですが言葉を当てた方がまだわかりやすいと思うので、皆さんもぜひ「Super AI Agent」という定義を使ってみてください。
We Are Hiring!
ABEJAは、テクノロジーの社会実装に取り組んでいます。 技術はもちろん、技術をどのようにして社会やビジネスに組み込んでいくかを考えるのが好きな方は、下記採用ページからエントリーください！ （新卒の方やインターンシップのエントリーもお待ちしております！） careers.abejainc.com
特に下記ポジションの募集を強化しています！ぜひ御覧ください！
