「自動化しています」の
中身を、ぜんぶ出します。
毎日使っているものだけを、実名で
AIで業務を自動化した、という話はよく聞きます。ただ、中身が出てくることはほとんどありません。 何を使い、どう繋ぎ、何が壊れて、何をやめたのか。そこが分からないと、聞いた側は自分の環境に持ち帰れません。
このページは、私が自分の本番環境で毎日動かしている仕組みそのものです。 構成も、判断の理由も、やらないと決めたことも、そのまま書いています。
姿勢のほうは AIとの向き合い方 に書きました。このページはその実装にあたります。
なぜ、自分の環境を公開するのか。
これは宣伝のためではなく、「実際どうなんですか」に答えるための準備です。
Windows Server・Azure・Microsoft 365 を中心に、企業のITを設計・運用してきました。その現場でいちばん困るのは、 「その製品、実際どうなんですか」に答えられる人がいないことです。 カタログ値も検証レポートも出てきますが、毎日使い続けた人の感覚だけは出てきません。
だから私は、自分の仕事環境を実験台にしています。新しい仕組みは検証環境ではなく自分の本番に入れて、壊れるところまで使います。 そこで分かったことしか、人には話しません。この順番を守るために、公開しています。
全体像。
人間がやることは2つだけです。思いついたことをタスク管理に放り込むか、チャットで話すか。どちらの入口も、使う製品は選べます。
① 入口
タスク管理とチャットの2つ。チャットは Teams でも Discord でも、裏で動くAIも選べます。
② 記憶
人間とAIが同じ1つの知識ベースを読み書きします。ここが効きます。
③ 実行
定期実行と自動化。壊れたら自分で気づいて、自分で直すところまで。
数字（実測）
実測日: 2026-08-22。この種の数字は放っておくと必ず古くなるので、載せるときは測った日を一緒に書きます。
止めたまま残している37件は、残骸ではなく残す理由があるものです。 有効に戻すと二重に動いて事故になるもの、止めていること自体が方針であるもの、再開の判断を自分に留保しているもの。 消すと、その理由ごと消えてしまいます。 逆に「もう戻さない」と決まったものは定義ごと削除します（2026-08-22 に44件を撤去しました）。 止めただけのものを「動いている数」に混ぜると、次に判断するときの材料が汚れるからです。
中身を、層ごとに。
上から順に、入口・中核・記憶・実行・連携・インフラ・発信・安全策の8層です。数字はすべて 2026-08-22 の実測値です。
01. 入口 — 入口は2つ。しかも、選べる
仕事を始める操作は2つです。タスク管理（Todoist）に放り込むか、チャットで話すか。 エディタを開くところから始めることは、ほとんどありません。
チャットからAIエージェントを動かす部分は自作して、オープンソースで公開しています （ebi-agent-chat-relay）。 1つのスレッドが1つの作業セッションになり、スレッドを分ければ複数の作業が同時に走ります。移動中でも入口は同じです。
ここで大事にしているのは、どこにも縛られないことです。
- 話す場所を選べる — Microsoft Teams でも Discord でも同じように使えます。対応する窓口は今後さらに増やします
- 頭脳を選べる — 裏で動かすAIは Claude Code でも Codex でも、手元のローカルLLMでも構いません。途中で切り替えられます
御社が Teams をお使いならTeamsから、社外に情報を出せない案件ならローカルのAIで。 「この製品を使う前提で」という条件を、こちら側の都合で押し付けないための構造です。
そしてもうひとつ。重要なのは「チャットで指示できる」ことより、会話がそのまま記録になることです。 何を考えて、何を選んで、何をやめたのかが、あとから全部たどれます。
02. 中核 — AIエージェントと、複数のAI
単発で質問するのではなく、調べる・直す・テストする・変更を提案するまでを一続きで任せます。
- 作業手順を133個、ファイルに書いて持たせている — プロンプトを毎回打ち直さないための資産です
- 調査・実装・レビューを別々のエージェントに同時に投げる
- レビューは別系統のAIに出す — 自分が書いたものを自分でレビューさせても甘くなります。Claude で書いたものは Codex に、というように意図的に系統を変えます
AIに全部任せて眺めている、という話ではありません。判断は人間が持ち、実行を任せる。この線引きだけは動かしていません。
03. 記憶 — 人間とAIが、同じ1つの知識ベースを読む
いちばん効いているのはここです。日々の記録、案件ごとの現在地、顧客ごとの文脈、技術メモが、全部同じ場所にあります。
- 「思い出して」と言えば、関連するノートを横断的に読んで文脈が復元されます
- 会話から生まれた知識は、その場で3つに振り分けます — これは何か／ハマって解決した／迷って選んだ
- 知識の生成・統合・剪定・整合チェックは、毎日の自動ジョブが回します
原則は「情報は一箇所に書く。ほかは全部ポインタ」。 同じことを2箇所に書くと、必ず片方が古くなって嘘をつき始めます。
04. 定期実行 — 自作した理由は、縛られないため
定期実行は自作の仕組みに一本化しています。cron も、既製のワークフローSaaSも使っていません。
cron を使わない理由は単純で、「いま何が動く予定か」を一覧できず、失敗しても静かだからです。
既製のSaaSに寄せない理由は別で、そこに全部載せると、あとから動かせなくなるからです。 自分で持っていれば、動かす場所（手元・クラウド・顧客環境）も、呼び出す先も、あとから選び直せます。 話す場所と頭脳を選べるようにしているのと、同じ理由です。
いまの形では、ジョブ定義と時刻設定がすべて1箇所に集まり、失敗すれば通知が飛び、 壊れを自分で見つけて直すジョブが回っています。 朝5時に予定・タスク・売上・リポジトリの状態が集まり、7時に要約が届きます。
05. 外部連携 — 固まった処理は直接API、探る場面は MCP
Microsoft 365・Microsoft Graph・Azure・ソースコード管理・カレンダー・会計まわりなど、外部サービスとは常時つないでいます。 つなぎ方は1つに決めず、用途で使い分けています。
- 毎日決まった形で動く処理 → 公式APIを直接叩くスクリプト。 失敗したレスポンスがそのまま見えるので、原因が自分の手の中に残ります。 認証まわりの罠（トークンの再利用、条件付きアクセス、権限スコープ）も、自分のコードにあるから直せます
- まだ形が決まっていない、いろいろ試したい操作 → MCP（AIが外部サービスを直接操作するための共通の口）。 たとえば会計の freee は MCP 経由で使っています。 何をどう取りたいかが固まる前の段階では、こちらのほうが速いからです
どちらが正しいという話ではなく、固まった処理か、探っている最中かの違いです。 探って形が決まったものは、直接APIのスクリプトに落として固定します。
一度書いたものは手順として登録し、次からはAIが同じやり方を再利用します。 「一度ハマったことは二度と調べ直さない」ための仕組みです。
06. インフラ — どこで動かすかも、あとから選べる
いまは手元に置いたサーバーを土台にし、その上に用途別の環境を載せています。 ただしこれは固定した選択ではなく、クラウドへ寄せることも並行して検討しています。
- 常時稼働の実行環境 — 定期実行とチャット基盤。ここが止まると全部止まります
- CI/CDランナー — ビルドを自前で回します
- GPU環境 — 画像生成・音声認識・ローカルLLM。外に出さずに処理したいものはここで回します
置き場所を選べる状態にしてあるのは意図的です。手元に置くほうが安いこともあれば、クラウドのほうが確実なこともあり、 その判断は時期と要件で変わります。変わったときに動かせるよう、特定の環境の作法に深く依存しない形で組んでいます。
一方で、GPUを手元に持っていること自体には固有の意味があります。 AIとの向き合い方で書いた「合意した情報をローカルで処理する」という経路は、 外に出さずに処理できる設備がなければ守れません。方針だけあっても、動かす場所がなければ守れないということです。
07. 発信 — 準備は自動、出すのは人間
動画・記事・SNSの発信も、下ごしらえはすべて自動です。動画を上げれば、文字起こしから内容理解、タイトル・説明文・サムネイル・分類まで自動で仕上がります。
ただし「公開する」ボタンだけは人間が押します。 AIが書いた文章をそのまま外に出して困ることは、実際に起きます。 自動化するのは準備までで、責任の発生する一線は越えさせない。この設計は仕事のやり方そのものと同じです。
08. 事故を前提にした運用
自動化が増えるほど、怖いのは静かに壊れることです。そして事故を完全に防ぐことはできません。 できるのは、起きる前提で組んでおくことだけです。だから固定している約束がいくつかあります。
- 複数の作業が同時に走る前提で作業する — 同じ場所を触るときは作業領域を分ける
- 秘密情報はコードに書かない — 環境変数か暗号化で保管し、起動時に存在を検証する
- 「やった」と「届いた」を分ける — 保存しただけ、APIが成功を返しただけでは完了にしない。実際に見える場所で確認する
- 失敗した記録を消さない — ハマった内容と原因を、その日のうちに知識ベースへ書く
考え方は一貫していて、壊れないようにするのではなく、壊れたと気づけるようにするほうに寄せています。 そのうえで試すことと、任せることは分けます。新しい仕組みを壊れるまで使うのは自分の環境の中だけで、 失敗が誰かに届く場所では、確認できるところまで下ろしてから動かします。
やらないと決めたこと。
構成そのものより、こちらのほうが役に立つかもしれません。
仕組みについて
- cron で定期実行する — 一覧できず、失敗しても静か。壊れていることに気づけない
- 特定のサービスに全部を載せる — 話す場所も、頭脳も、動かす場所も、あとから選び直せる形にしておく
- つなぎ方を1つに決める — 固まった処理は直接API、探る場面は MCP。用途で使い分ける
- 同じ情報を2箇所に書く — 必ず片方が古くなり、古いほうを信じて事故が起きる
姿勢について
- AIに公開ボタンを押させる — 準備までは任せられるが、外に出す責任は人間が持つ
- 止めた自動化を「動いている数」に混ぜる — 実態より大きく見せると、判断を誤るのは自分
- 試していない製品を勧める — 毎日使ったことしか、本当のことは言えない
この環境が示せること、示せないこと。
✅ 示せること
- 設計だけでなく実際に構築して運用していること
- 人が見ていなくても動き、壊れたら気づける構造を作れること
- 手元の環境だけでAIを動かす設備を現に持っていること
- 自動化をやめる判断も含めて回していること
🚧 示せないこと
- これは一人分の環境です。数百人規模の統制がそのまま同じ形になるわけではありません
- 自分の環境なので、止まっても謝る相手がいません。その分だけ大胆にできています
- ここに書いた構成は今日時点のものです。半年後には別のものに入れ替わっている部分があります
「うちでも、これくらい自動で回るようにしたい」
どこから手を付けるかは、今どこが手作業で、どこが静かに壊れているかによって変わります。まずは今の状況を聞かせてください。この環境の中で、御社に持ち込めそうな部分を具体的にお話しします。
フォームからのご相談と、こちらからの返信は無料です。