チャットだけでは「AI活用」とは言えない。オートメーション・コンテキスト・エージェントこそがAI活用の入口。

世の中で語られるAI活用の大部分がチャットアプリのプロンプトに集中しています。確かにプロンプトエンジニアリングとしては、良いプロンプトの書き方が価値ある議論であることは間違いありません。

ただ、チャットアプリによるAI利用は、人間の能動的行動が起点になります。AIは受動的であり、100セッションあれば、100プロンプトが必要なため、人間の時間と注意を消費し続けます。個人的な実感として言えば、今年最大のワークフロー革命はチャットとは別の場所で起きています。

• 第1に、AIによるオートメーション。
  人間が指示しなくてもAIが定時に動き、状況を判断し、必要な相手に必要な情報を届ける仕組みです。業務において本当に効くのは人間が指示しなくてもAIが動いている時間を増やすことです。これが第1の革命であるオートメーションです。

• 第2に、AIに埋め込むコンテキスト。
  コンテキストが肥大化することで、AIは前に話したことを省略していきます。前提条件を毎セッションで繰り返すのは現実的ではないため、セッションごとに最適なコンテキストを埋め込む仕組みを使います。コアファイル・コネクトデータ・スキルやルールをあらかじめ構造化してAIに渡しておく設計です。

• 第3に、AIエージェントによる駆動。
  複雑な仕事は1つのAIに全部任せると質が落ちます。「ヒアリングして、リサーチして、コピーを書いて、批判して」を1つのプロンプトで頼むと、どの工程も中途半端になります。1体のチャット相手としてのAIではなく、役割を持った複数のAIが互いにチェックし合いながら一つのアウトプットを作り上げる構造です。

この3つは、いずれもチャットアプリの外側で進行しているため、AIをチャットとしてだけ使っている人からは見えにくい場所にあります。本稿では、私が個人で組み上げて運用している10系統のワークフローを、この3つの軸で再整理し、技術的なポイントを掘り下げていきます。

AIによるオートメーション

私が個人で運用している自動通知のインフラは4系統あります。なぜ4系統も必要なのか、というところに、オートメーション設計の勘所が現れています。

1つ目はGAS (Google Apps Script) です。
勤怠連絡の通知などチャンネル全体で使う目的で、Slack APIとGemini APIを組み合わせた簡単な投稿処理に使っています。

2つ目はGoogle Cloud Runです。
GWS全体の権限を超えた議事録要約とSlack DM配信に使っています。GASではタイムアウトになりやすい長文処理や、各種APIへの安定したリクエストが必要な場合に、Cloud Run上のコンテナで動かす形式です。

3つ目はClaudeデスクトップアプリのスケジュール実行です。
これは自分専用の用途、つまり「自分のタスク確認」「日報・週報の作成」のような個人スコープに限定して使っています。

4つ目はWorkspace Studioです。
メールで届く休暇申請や捺印申請、請求書PDFが添付されたメールの自動保存など、Googleサービスのトリガー判定からのオートメーションを担当しています。

エンジニアとしてはなぜ1つに統一しないのかと疑問に思うところだと思います。実際に運用してみての答えは、どのインフラも得意領域が違うため、無理に統一すると弱いところで詰まるというものでした。GASに長文処理を載せるとタイムアウトしますし、Cloud Runに勤怠連絡だけのために認証基盤を作るのは過剰です。Coworkは個人スコープを超えると運用負荷が上がります。

オートメーションが革命だと言える理由は、人間の介在ゼロで情報の流れが回り続ける、という構造そのものにあります。チャットを開く必要も、プロンプトを打つ必要もありません。

朝起きたらすでに昨日の議事録の要約が届いていて、残業申請が来たらSlackにメンションが入っていて、日々の判断に必要な材料が自動的に手元に揃っている状態です。これはチャットだけのAI活用では到達できない景色です。

AIに埋め込むコンテキスト

第2の革命は、コンテキストの埋め込みです。

私の業務では、Hubspotとboardのデータを、Claude CodeがPythonでAPIから取得する仕組みを組んでいます。SKILL呼び出しで自動実行される設計です。

これによって、AIは私の業務コンテキスト、つまり「どの案件が進行中で、どこに請求が立っていて、コストはどうなっているのか」をプロンプトで説明しなくても保持できるようになります。チャットの開始時に毎回「うちの会社はこういう構造で」と説明する必要がなくなる、という意味で、これも革命の一部です。

サイト分析の領域でも同じ構造を採用しています。similarwebやAhrefsのPDFレポートはGoogle Driveに置き、Claude in Chromeが読み解きます。GA4のCSVファイルはClaude Cowork上で読み込みます。データソースの形式に合わせて、AIが取りに行く経路を変えるという発想です。

Shopify APIやShopify CLIのように、認証情報の管理が現実的な範囲で済む場合は、CLIやAPI経由が圧倒的に有利です。リクエストの再現性が高く、エラーハンドリングを書きやすく、CI上でテストもできます。

一方、Shopify管理コンソールのように、GUIでしかできない設定変更や、APIで提供されていない機能がある場合は、SidekickエージェントがGUIを操作するアプローチを取ります。APIなら冪等性を担保しやすいですが、GUI操作はその時のUI状態に依存するため、再現性のテストが難しくなります。重要な操作はAPIに、参照や分析のような副作用の少ない操作はGUIに、というのが現時点の落とし所です。

AIエージェントによる駆動

第3の革命がエージェントです。私の運用の中で、もっとも質的な変化が大きかった領域です。

提案書ワークフローの設計を例に見てみます。提案書ワークフローでは、SKILLという形でAIに業界知識・過去の提案パターン・判断軸を事前に設定しています。プロンプトに毎回書き込むのではなく、コンテキストとして必要に応じてロードさせる発想です。

ClaudeのコマンドからSKILLを呼び出すと、「ヒアリング → イシュー定義 → リサーチ」という流れが自動的に進みます。
出力されたドキュメントをGeminiにレビューさせる「A to Aチェックループ」に流し、その後「ストラテジー → ディレクター → コピーライター → レッドチーム」という4つのエージェントが順番にレビューを入れます。レッドチームというのは、出来上がった案に対して批判と反論を専門に行うエージェントです。

ここでのポイントは、1体のAIに全てを任せていない、ということです。1つのプロンプトで「ヒアリングして、イシューを定義して、リサーチして、コピーを書いて、批判して」と頼むと、各工程の質が中途半端になります。役割で分けたほうが、各工程の精度が出やすい。これは人間のチーム編成と同じ原理が、AIエージェントにもそのまま当てはまる、という発見でした。

もう1つ重要な設計が、人間をループの出口に置くという発想です。AIエージェント同士のAtoAチェックループの中には人間を入れません。入れてしまうと、AIが出すたびに判断する作業が発生し、結局AIに毎回指示を出す人になってしまうからです。代わりに、ループから出てきた最終ドラフトに対してだけ、自分が品質を確認します。書く時間ではなく、見る時間に自分を寄せる、という配分です。

エージェントは提案書ワークフロー以外にも展開しています。Shopify管理コンソール上で動くSideKickは、売上分析・顧客セグメント作成・GraphQL生成・Shopify Flowによる自動化作成までを自律的に行います。

Claude Codeでは、Shopify CLI経由でUI Extensionアプリを作成したり、ローカルフォルダの画像をPython処理で透過PNGに変換したり、2つのフォルダの差分をチェックしてリネーム・移動・Google Driveへのアップロードを実行したりします。これらは私が指示を細かく書かなくても、AIが手足となって作業を進める状態を作り出しています。

ハルシネーションや機密情報漏洩リスクは残るため、レッドチームのような事実確認エージェントを明示的にチェーンに組み込むといったハーネスは必要ですが、設計次第で品質を担保できることが分かってきました。

エージェントの面白さは自律的に動く点よりも、役割を分けて連携させる設計が効く点にある、というのが私の感触です。
1つの汎用的なAIを召喚するのではなく、専門性に特化させた責任範囲の小さいAIを並べてつなぐ。トークンの節約にもなり、失敗時の切り分けもしやすく、各エージェントへのプロンプト改善も独立して進められます。

3つを束ねる設計原則

オートメーション・コンテキスト・エージェントの3つを並行して動かしてみると、共通する設計原則が見えてきます。

• 第1に、人間をループの出口に置く。
  AIが回るループの中に自分を入れず、最終アウトプットを確認するレイヤーに自分を寄せます。

• 第2に、道具を統一しすぎない。
  GAS・Cloud Run・Cowork・Code・Workspace Studioを並行運用しているのは、それぞれに得意な領域があるからです。新しい技術が入っても、設計の判断軸は意外と変わらない、という再発見でもあります。

• 第3に、CLIとGUIを使い分ける。
  再現性と冪等性が必要な処理はCLIに、UIの解釈が必要なブラウザ処理はエージェントのGUI操作に寄せます。

• 第4に、アプリ化と自動化を分けて持つ。
  能動的に呼びたいものはアプリインターフェイス、勝手に動いてほしいものはいつものインターフェイスからAPIを通して自動処理に整理します。社内向けに作っているプロジェクト進捗サマリーレポート生成アプリや、Slack /taskコマンドによるタスク・カレンダー一括作成アプリは、この原則に基づいて自動化と切り分けて配置しています。

これらは、AIが入ってきたから新しく生まれた原則というよりは、業務インフラ設計で従来言われてきたことが、AIエージェントを組み込む際にもそのまま効く、という構造です。

革命はチャットの外で起きている

冒頭の主張に戻ります。AI活用 = チャットとプロンプトだと思っているうちは、革命の入口にしか立っていません。

本当の革命は、AIがオートメーションとして人間の指示なしに動き、コンテキストを埋め込まれて最適な文脈や手順を選び取り、エージェントとして役割を分け合いながら自律的に作業を進める、という3つの軸で進行しています。これらは全て、チャットを開いていない時間に起きていることです。

エンジニアにとって、AIを業務に組み込むという仕事は、新しいフレームワークを覚えるというよりは、自分の周りのデータフローを再設計する仕事に近づいてきている、というのが現時点での感触です。
どのデータをどのインフラに流し、どこに自分の判断を置くか。これらの問いは、AIが登場する前から業務システム設計の中心にあった問いそのものです。

10系統のワークフローを並べてみて見えてきたのは、AIが手足となって実際の作業を実行してくれること。これが今年最大の革命であり、その本体はチャットウィンドウの向こう側、つまり業務インフラの設計の中で静かに進行しています。