なぜ今、AIワークフローと業務自動化を「自分で設計」するのか——MIMIRシステム開発ブログ 第1回

「AIって便利そうだけど、結局チャットに質問するだけでしょ？」

そう思っていた時期が、私にもありました。しかし2026年の今、AIの世界は静かに、しかし確実に次のステージへ移行しています。単なる質問応答から、目標を与えると自ら計画・実行するAIエージェントへ——この変化は、業務自動化やAIワークフロー設計のあり方を根本から塗り替えようとしています。私が開発している「MIMIR（ミミル）」は、その変化の最前線に立つ試みです。

Salesforceの調査によれば、企業におけるAI導入率は前年比282%増という驚異的なペースで拡大しており、2026年には企業の80%以上が何らかの形でAIエージェントを業務に組み込むと予測されています。

この連載を書こうと決めたのは、「成功した後に振り返って書く」ためではありません。設計の途中、判断の瞬間、失敗の直後に書くためです。「なぜこの設計にしたか」という判断の背景こそが、完成した製品からは消えてしまう、最も価値ある情報だと考えているからです。

MIMIRをゼロから作り上げる過程を、成功も失敗も包み隠さずお伝えします。技術的な誠実さを武器に、読者の皆さんと一緒に考えていきたいと思います。

AIワークフローとエージェントの違い——2026年、定義がシフトした瞬間

「AIエージェント」という言葉は、2025年ごろから急速に使われるようになりました。しかし正直なところ、言葉だけが先行して実態が曖昧なまま語られているケースが多い印象です。まず定義を整理しておきましょう。

旧来のAI活用と、エージェントの決定的な違い

簡単に言えば、「何を作るか聞いてくれるAI」から「材料を集めて設計して実際に組み立てるAI」への進化です。

私たちが日常的に触れているAIツール——たとえばClaude CodeやNotebookLM、GeminiのGems、ChatGPTのGPTs——は、いずれも優れたサービスです。しかしこれらは基本的に「ユーザーが質問・指示を与え、AIが応答する」という構造を取っています。対してAIエージェントは、目標を与えられると自ら必要な手順を考え、ツールを呼び出し、結果を検証しながら完遂まで動き続けます。この差は、使い勝手の差ではなく、仕事の構造そのものの違いです。

技術的な背景：ReActパターンとマルチエージェント

この変化を支えているのが、「ReAct（Reason and Act）」と呼ばれる設計パターンです。エージェントが「考える（Reason）」と「行動する（Act）」を交互に繰り返すことで、複雑なタスクを段階的に解決します。

さらに2026年時点では、マルチエージェントシステム——役割の異なる複数のエージェントが分業・協調して動く——が主流になりつつあります。調査担当、執筆担当、チェック担当のエージェントがそれぞれ専門性を持ち、連携して1つの成果物を作り上げるイメージです。

LangGraphのようなワークフロー制御ツールの普及が、こうした自律的エージェント構築を「概念実証（PoC）」から「実務レベル」へ引き上げた技術的基盤となっています。

業務自動化の現場で感じた限界——MIMIRが生まれた背景

「n8nやMake、あるいはClaude APIで十分じゃないか」という声はよく聞きます。実際、私自身もクライアントへの提案でn8nを使った業務自動化ワークフローのデモを行いました。チャットツールを起点とし、Whisperで音声解析・話者分離を行い、Claude/Geminiを組み合わせた議事録自動化はニーズもあり、確かに強力です。

しかし現場に入ると、技術トレンドとは少し違う構造の課題が繰り返し現れます。

ある歯科医院との会議でのことです。院内の取り組みや経営数値を共有していただく中で、「今AIにどこに力を入れるべきか」という問いに対して、私はこう答えました。「記録を残すことに一番注力するべきです」と。

議事録、患者の反応、スタッフの気づき——これらは現場で毎日生まれているのに、ほとんどが誰かの頭の中にしか存在しない。記録されないから分析できない。分析できないから改善のサイクルが回らない。

2026年の現在、こうした「記録・蓄積・暗黙知の形式知化」は、AI活用以前に、失敗リスクがなく将来の価値を生む金の卵になり得ます。業務自動化やAIワークフローの恩恵を最大化するための土台は、今日積み上げるデータにあるからです。特に日本の製造業にとっては喫緊の課題であり、今からデータを蓄積し暗黙知を形式知化していくことが、AIがさらに発展していく世界線で決定的な競争優位につながります。

別のクライアントとの会議では、「将来の有料客を獲得する目的でコンテンツをやる」という方針が決まり、Webに載せる情報は医院の思想に共感する人を引き寄せるフィルターだという設計になりました。方針は正しい。しかし「そのコンテンツを誰がどのように継続して生産するか」という問いに、現場はまだ答えられていない。

さらに別の会議では、n8nのデモをした際、経営者の方から「自分の日々の思考を自動で整理・活用できる『社長ボット』を作りたい」という声が上がりました。

これらの現場に共通しているのは、「情報は現場に眠っているのに、それを活かす仕組みがない」という構造的な問題です。既存の汎用ツールでこれを解決しようとしたとき、私は3つの限界を感じました。

既存ツールで感じた「3つの限界」

① 文脈の喪失問題

既存のワークフローツールは「フロー」は作れます。しかし過去の会話・判断・失敗の履歴を横断的に参照しながら今の状況を判断することが苦手です。毎回「白紙から始める」エージェントには、経験が積み重なりません。人間でいえば、毎朝記憶をリセットして出社するか、昨日の会議の内容を踏まえて今日の仕事を始めるかの違いです。

また、既存のチャットボットは、あらかじめデータを整備して情報ソースとしてインプットする手間がかかり、言語化されていない情報を扱うことができません。その結果、データとして登録できる内容は限定的で、鮮度の低いものになりがちです。データ登録のコスト（手間）自体も、現場にとって大きな負担です。

なお、AIエージェントのスキルに記憶保存の設計を組み込む工夫によって、ある程度の記憶保持は実現できます。しかし、もれなく情報を記録していくためには一定の専門知識が必要であり、これは現在も取り組み続けている課題です。

② 評価プロセスの不在

「タスクが終わった」ことは分かっても、「タスクがうまくできたか」を自律的に評価する機能を持たせるのは、既存ツールでは追加実装が必要です。品質の担保が人間依存になってしまう。

AIエージェントが出力した成果物を、別のAIエージェントが評価するプロセスを組み込むことで、一定の品質を担保することができます。

また、人間が行う毎日の業務や活動内容が、設定した目標に向けて前に進んでいるのか。矛盾した行動を取っていないか、今優先すべき活動は何なのか？といったことを、デイリーで振り返り、AIによる示唆や提案をもらうことも可能です。

ほかにも会議のファシリテーションは上手にできたのか、話す速度は適切だったのか、といったこれまで専門のツールで行い分断されていた情報を、音声ファイルの送信から議事録作成・ファシリテーションの評価までを一気通貫で行うといたことも可能になります。

③ 属人的な「ノウハウ」がシステムに宿らない

経営者が長年で培ってきた判断軸や価値観——「こういうときはこう動く」という暗黙知——を、システムの中に埋め込みたいと考えたとき、汎用ワークフローツールでは限界があります。

そもそも暗黙知を言語化していくためには、いかに日常の中で少ない負荷で情報を記録するのかという仕組みが必要です。打ち合わせのデータ解析も重要ですが、チャットや音声でつぶやいたり、手書きのメモの写真、本を読んだ感想やニュースへの反応——といった様々な情報を、システムに放り込むだけで自然に整理・抽出する仕組みが必要でした。

これらの3つの課題を解決するために、MIMIRの設計を始めました。

MIMIRの設計思想——「なぜそう作るか」を公開する

MIMIRという名前は、北欧神話に登場する「知恵の泉の守り手」に由来しています。情報を蓄積し、意味を生み出す存在。その名前の通り、MIMIRは「情報を処理して答えを出す」だけのシステムではありません。

多くの開発ブログが「こう作りました」という結果を語ります。私が大切にしたいのは「なぜこの設計にしたか」というプロセスです。その理由は、設計思想そのものが最大の資産だと考えているからです。

📌 正式名称について

MIMIRの正式名称は MIMIR — Message-Informed Memory for Intelligent Retrieval です。「メッセージから得た情報を記憶し、インテリジェントな検索・参照を実現する」というコンセプトをそのまま名前に込めています。

設計の核心：3つの柱

柱1：長期記憶（Memory）アーキテクチャ

単純なベクトルDB保存ではなく、「事実の記憶」「判断の記憶」「成功/失敗の記憶」を別レイヤーで管理するメモリ構造を検討しています。なぜ分けるのか。失敗から学ぶためには、「何が起きたか」と「なぜ失敗したか」を切り離して記録・参照できる構造が必要だからです。

Notionをデータハブとすることで情報の蓄積と二次利用が容易になる——これは単なる整理整頓の話ではありません。AIエージェントが過去の文脈を参照できる「長期記憶」を持てるかどうかは、システムの賢さを決定的に左右します。

ここで一点補足します。AIワークフロー基盤としてはDifyのようなノーコードツールという選択肢もあります。それでもあえてNotionというリレーショナルデータベースをデータハブとして採用しているのには、明確な理由があります。

第一に、情報のコントロールが目に見える形でできること。どのデータがどのような構造で蓄積されているかを、非エンジニアでも確認・編集できる透明性は非常に重要です。第二に、生成AIは強力ですが、何を根拠にその結論に至ったのかが見えにくいという問題があります。NotionをハブにすることでAIの参照元を可視化でき、「なぜその回答が出たか」を追跡できます。第三に、社長の哲学や経営判断といったプライベートな文脈を安心してインプットしてもらえる設計にするためには、情報の所在と制御が透明である必要があります。Notionはその信頼の土台になります。

柱2：自己評価（Self-Evaluation）ループ

タスク完了後に「自分の成果物を採点する」エージェントを独立して配置します。実行エージェントと評価エージェントを分離することで、自己欺瞞（良い結果に見せかけること）を防ぎます。これはマルチエージェント設計の恩恵が最も大きい部分です。

具体的な実装アプローチとして、複数のエージェントにそれぞれアウトプットを出力させ、それらを元に議論・比較させる工夫も取り入れています。さらに、DeepResearchや過去の議事録を参照したファクトチェックも実施しており、評価の根拠を多角化することで精度の向上を図っています。

なお、現時点で最も頭を悩ませているのは「評価基準の設計」そのものです。「何をもって正しいとするか」——この問いに答えを出すことが、品質担保の鍵になります。

柱3：人間との協調インターフェース（Human-in-the-Loop）

重要な判断点では必ず人間に確認を求める設計を標準装備します。完全自律化が目標ではなく、「人間がより本質的な仕事に集中できる状態を作ること」が目標です。

ただし、Human-in-the-Loopは業務自動化を設計するうえで非常に重要な考え方である一方、せっかくAIで効率的にできることが、人間が介在することで逆に足を引っ張る構造になるケースも少なくありません。確認フローが増えすぎてボトルネックになる、判断の責任が曖昧になるといった問題です。

MIMIRでは、人間の介在が必要な判断ポイントをあらかじめ設計段階で明示し、それ以外のプロセスはエージェントが自律処理するよう役割を明確に分離することで、この問題の緩和を図っています。

ここで強調したいのは、AIエージェントを使いこなすには、むしろ人間のマネジメント能力が以前より高く求められるという逆説です。何をゴールに設定するか。どの情報をインプットとして与えるか。出力の品質をどう評価するか。エラーが起きたときにどう対処するか。これらは全て人間が判断しなければならない。

AIは「デジタル同僚」であり、放置すれば暴走するし、適切に指揮すれば驚くほど仕事をする存在です。MIMIRは、その「指揮しやすさ」を設計段階から組み込んでいます。

直面している「本当の難所」——PoC段階の正直な話

ここで少し泥臭い話をさせてください。華やかな構想の裏側で、現在進行形で悩んでいることがあります。

難所1：ハルシネーションとの戦い

「本番環境での信頼性」は、2026年のAIエージェント業界全体が抱える最大のボトルネックです。エージェントが複数ステップを踏む中で、一度の誤りが次のステップに伝播し、最終的な出力が大きく外れることがあります。評価エージェントによる中間チェックを設計していますが、「何をもって正しいとするか」という評価基準の設計そのものが難しく、現在も解決途中の課題です。

難所2：セキュリティと監査可能性

エージェントが自律的に動くということは、「何をしたか」の追跡が必要になります。ただし、全ての行動ログをリアルタイムで監査するのは現実的ではありません。そこでMIMIRでは、センシティブな情報がインプットされた際にそれを自動的にラベリングし、本人の承認を得ないとAIが情報源として参照しない仕組みを設計に組み込む方向で検討しています。

完璧な監査体制よりも、「重要な情報の取り扱いをコントロールできる設計」を優先する考え方です。一方で人間の監査・承認を得るプロセスを組み込むことで、せっかくインプットした情報が有効化されるまでにタイムラグが発生してしまう。AIによる自動処理のルールや閾値の設定、人間の介入が必要なポイントやインターフェースの設計。これが想定以上に実装コストを押し上げている課題でもあります。

難所3：「社長の思考」をどうシステムに落とし込むか

最も哲学的な難所がここです。「経営者の暗黙知をAIに学習させる」という構想——いわゆる「社長ボット」——は技術的に面白いテーマですが、実現には複数の壁があります。

言語化されていたとしても、それを整理してシステムにインプットすることは相当な手間がかかります。そもそも、経営者の判断軸の多くは言語化されていないケースがほとんどで、これまでこのアプローチは非常にハードルが高いものでした。しかし生成AIの発展により、音声や画像解析、視線のトラッキングやセンサーの活用などで暗黙知を抽出しやすくなってきており、状況は変わりつつあります。

現在試験的に取り組んでいるのは、毎日5分、一日のデイリーサマリーをもとに振り返りを行い、ボイスメモを蓄積するという方法です。そこから文字起こしして抽出した情報や、会議の中の特徴的な発言を一般化・抽象化して「哲学カード」として整理し、根底にある考え方としてAIが参照する仕組みを構築しています。手軽に続けられる点で感触が良く、議事録・判断履歴・価値観ドキュメントとあわせて、MIMIRの最もコアな設計課題に取り組む入口として機能し始めています。

2026年、AIエージェント開発者が考えるべき「人間の役割」

最後に、少し視野を広げた話をします。

フィジカルAI・自動運転など現実世界へのAI進出により、AIの活動領域は「画面の中の作業」から「現実世界のオペレーション」にまで広がっています。NISTが「AI Agent Standards Initiative」としてエージェント間通信やツール連携のプロトコル策定を始めていることも、この方向性を示しています。標準化が進めば、MIMIRのような独自システムと外部エージェントの連携もより現実的になるはずです。

「AIが自動化すれば楽になる」という論調は、半分正しくて半分間違いだと私は思っています。AIワークフローや業務自動化を使いこなすには、新しいマネジメント能力——AIに「何をやらせるか」を設計し、「どう評価するか」を判断し、「どこに人間が介在するか」を決める能力——が必要になるからです。

AIは道具ではなく、一緒に働く「デジタル同僚」です。良い同僚関係を作るには、良いマネジメントが必要です。そしてMIMIRは、その「マネジメントしやすいAIチーム」を実現するための設計です。

次回予告——MIMIRのシステム構成図を公開します

第1回では「なぜ作るか」という思想の部分をお伝えしました。第2回では、現在のMIMIRのシステム構成図と、使用している技術スタック（LangGraph、Notion API、Slack Webhook等）を具体的に公開する予定です。

設計の迷いや失敗も、判断の瞬間に書いていきます。「同じような課題を感じている」「こういう設計はどうか」——そんなフィードバックをお持ちの方は、ぜひコメントやSNSでご意見をお寄せください。AIエージェント開発は、まだ誰も正解を持っていない領域です。一緒に考えていきましょう。

この記事を読んだあなたへ

MIMIRの開発は、LOFIRが支援するクライアントの現場課題から生まれています。「AIエージェントを自社業務に組み込みたい」「n8nやNotionを使った業務自動化ワークフローを導入したい」「自社の暗黙知をシステムに落とし込みたい」——そういった課題感をお持ちの方は、ぜひ一度話しましょう。あなたの現場の話が、次の設計のヒントになるかもしれません。

👉 LOFIRへのお問い合わせはこちら