仕事のタスクは、タスク管理アプリの中で生まれるわけではありません。
Slackで「明日の会議までに競合3社の料金を調べてほしい」と頼まれたり、会話の中で「この内容、あとでまとめて共有しておいて」と言われたり。日々のコミュニケーションの中で、仕事は次々と生まれています。
しかし、その仕事を実際に進めるためには、人が「これはタスクだ」と認識し、タスク管理アプリに登録し、内容を整理し、あとから見返して実行する必要があります。
つまり、仕事そのものとは別に、仕事を管理するための仕事が発生しています。
一方で、AIは文章を生成するだけでなく、Webを検索し、外部サービスを操作し、複数のステップにまたがる仕事まで実行できるようになっています。
だとすると、次に減らせるのは「仕事」だけではなく、仕事を管理する行為そのものなのではないか。
そんな問題意識から、今回のAI HACK 2026（お題：業務を自立化するAIエージェント）で、Optioを作りました。
1. タスク管理そのものを減らしたい
1-1. 「仕事を管理する仕事」がある
現在のタスク管理では、仕事が発生してから実行するまでの間に、人がいくつもの管理作業を行っています。
タスク管理アプリは、この一連の作業を便利にしてくれます。期限を通知したり、担当者を割り当てたり、プロジェクトごとに整理したりできます。
ただ、どれだけ便利になっても、その前提として残るものがあります。
最初に人が「これはタスクだ」と認識し、管理対象に載せなければならないことです。
Slackで依頼された仕事を登録し忘れれば、そのまま流れていきます。会話の中で生まれた仕事なら、「あとで登録しよう」と思ったまま忘れることもあります。
Optioが減らしたかったのは、この部分です。
目指したのは、より高機能なタスク管理アプリではなく、人がタスク管理を意識しなくても仕事が前に進んでいる状態です。
1-2. 仕事のスタート地点を変える
最近の業務ツールにも、AI Agentや自動化機能が増えています。
NotionではTriggerやScheduleからCustom Agentsを動かせますし、AsanaにもWorkflowの中で仕事を進めるAI Teammatesがあります。
つまり、タスク管理ツールにAIが搭載されていること自体は、すでに珍しくありません。
Optioで変えたかったのは、AI機能の有無ではなく、仕事がどこから始まるかです。
| 主な起点 | AIの主な役割 | |
|---|---|---|
| 従来のタスク管理 | 登録されたTask / Project | 整理・通知・管理 |
| AIを組み込んだWork Management | Task / Workspace / Trigger | 自動化・実行 |
| Optio | 日常の会話・Slack | 仕事の発生を見つけるところから始める |
Optioでは、最初にタスク管理アプリを開く必要がありません。
普段通りSlackを使い、普段通り人と話します。その中からOptioが「これから実行すべき仕事が発生した」と判断したときだけ、仕事を前へ進めます。
1-3. 「AIにお願いする」という操作も減らす
AIサービスにも、人から依頼された仕事を複数ステップにわたって進めるものが増えています。
ただし、その場合も基本的には、人が仕事を認識し、AIを開き、改めて依頼内容を入力してから処理が始まります。
Optioでは、そのさらに前から処理を始めます。
「AIに仕事を依頼する」という操作自体を減らしたい。
これがOptioの基本的な発想です。
2. Optioはどう仕事を進めるのか
2-1. 5つのステップで処理する
ユーザーがすることは、普段通り話して、普段通りSlackを使うことです。
その裏側でOptioは、仕事を5つの段階に分けて処理します。
たとえばSlackで「明日の会議までに競合3社の料金を比較してまとめてほしい」と依頼されたとします。
Optioはまず、そのメッセージに実行すべき仕事が含まれているかを判断します。
タスクであれば、何をするのか、何のためにするのか、期限はいつか、実行するために足りない情報がないかを整理します。
そのうえで、AIがそのまま実行するのか、人の承認を挟むのか、人が対応するのかを決めます。
| 実行方法 | 動作 |
|---|---|
ai |
AIがそのまま実行 |
approval |
人が承認したあとAIが実行 |
human |
人が対応 |
何でもAIにやらせることを目標にはしていません。
必要な情報が揃っている調査や要約などはAIが進めます。一方で、情報が不足している場合は勝手に推測せず、人に戻します。確認を挟むべきと判断された仕事は、承認されるまで止めます。
2-2. ユーザーに見せる状態は3つだけ
内部では処理の進行状況を細かく管理していますが、そのままUIには出しません。
ユーザーが知りたいのは、Agentが内部で何をしているかではなく、**「今、自分が何をすればいいのか」**だからです。
そこで、画面上では次の3つにまとめました。
| 状態 | 意味 |
|---|---|
| あなたが対応 | 判断・承認・人の作業が必要 |
| AIが対応中 | AIが処理を進めている |
| 完了 | AIまたは人による処理が完了した |
Agentの内部状態ではなく、人が次に取る行動へ変換して表示することを意識しています。
3. システム全体像と技術選定
3-1. 全体構成
Optioは、大きくDesktop App、Cloudflare上のBackend、AIサービス、SlackやMCPなどの外部サービスから構成されています。
Voiceの場合はDesktop Appでマイク入力を取得し、端末内で文字起こしします。音声そのものはBackendへ送信せず、文字起こし結果だけを送ります。
Slackの場合は、メンションやDM、参加しているスレッドへの返信を受信します。
Backendでは、まず入力の中にタスクが存在するかを判定します。タスクでなければそこで処理を終了し、タスクと判断されたものだけをより深い理解へ進めます。
現状のタスク理解では、まず入力メッセージそのものをもとに、タスクの目的・期限・背景・不足情報を整理します。その後、AIが実行するのか、人の承認を挟むのか、人が対応するのかを判断します。
AIで実行できるものは別の非同期Workflowへ送り、接続済みのSlackやMCPサービスのツール、またはWeb検索を必要に応じて使いながら処理を進めます。
3-2. 技術選定
| レイヤー | 技術 | 主な理由 |
|---|---|---|
| Desktop App | Tauri 2 / Rust / React 19 / Vite / TypeScript | ネイティブ処理とWeb UIを両立するため |
| 音声処理 | cpal / whisper-rs / Metal / rubato | 音声を端末内で文字起こしするため |
| 端末内保存 | SQLite / rusqlite | 通信失敗時にも文字起こし結果を保持するため |
| API | Cloudflare Workers / Hono | 認証、入力受付、タスク操作を担うため |
| 非同期処理 | Cloudflare Workflows | タスク理解・AI実行・再試行をAPI受付から切り離すため |
| Database | Cloudflare D1 | タスク、実行状態、実行履歴、連携情報をBackend側で管理するため |
| 判断・分類 | JEV | タスク判定と、AI・承認・人への実行方法の振り分けを行うため |
| 生成・推論 | OrcaRouter API / Gemini | タスク理解とAgent実行を行うため |
| 外部連携 | Slack API / MCP | 接続済みの外部サービスをAgentの実行ツールとして扱うため |
4. 一つの巨大なAgentにしなかった
4-1. 処理ごとに必要な能力が違う
最も単純に作るなら、VoiceやSlackの入力を一つのAgentへ渡し、タスク判定から外部Toolの実行まで全部任せる方法もあります。
ただ、Optioではこの構成を採用しませんでした。
日常会話やSlackには、雑談、報告、質問、過去の仕事についての説明、これから実行すべき依頼などが混ざっています。
そのすべてに対して毎回大きなモデルを動かし、さらに外部ツールを渡す必要はありません。
また、「タスクが発生したかを判断すること」と「タスクの内容を理解すること」と「実際に外部サービスを操作すること」では、必要な情報も権限も異なります。
そのためOptioでは、判断、理解、実行を分離する構成にしました。
4-2. 判断するAIと、考えるAIを分けた
Optioでは、すべてのAI処理を同じモデルに任せていません。
JEVが担当するのは、タスクかどうか、そしてAI・承認・人のどれに振り分けるかという判断です。
一方、入力内容からタスクを理解したり、文章を生成したり、複数ステップの処理を進めたりする部分では、OrcaRouter経由のAIモデルを利用します。
タスク判定で欲しいのは長い文章ではなく、TaskかNot Taskかという判断です。同様に、実行方法を決めるときも、欲しいのはai、approval、humanのどれかです。
そこで、選択や分類はJEVへ寄せ、より深い理解や生成が必要なところからLLMへ進める構成にしています。
5. ContextとToolを必要な範囲に絞る
5-1. タスクと分かるまでは深く調べない
VoiceやSlackから入力が届いた時点では、まだタスクかどうか分かりません。
そこで、最初からSlackのスレッド全体を取得したり、Google WorkspaceやNotionなどを検索したりすることはしません。まず入力そのものからタスクかどうかを判定し、タスクではなければそこで終了します。
現状のMVPでは、タスクと判定された後も、まずはその入力メッセージだけを使ってタスクを理解します。周辺スレッドや外部サービスからの追加コンテキスト取得は、データモデルと連携基盤を用意している今後の拡張領域です。
会話やSlackは大量に発生するため、安い処理から始めて、必要になったものだけ深い処理へ進めることを意識しています。
5-2. 情報が足りなければ勝手に補完しない
「例の3社、明日までに比較しておいて」のように、メッセージ単体では意味が完結しない場合があります。
現状では、その入力だけで一次アウトプットを作れないと判断した場合、不足情報を持つタスクとして保存し、人が対応する状態へ戻します。AIが足りない情報を推測して、そのまま実行することはしません。
将来的には、Slackのスレッドや接続済みサービスから必要なコンテキストを追加取得し、それでも不足する場合だけ人へ戻す形を目指します。
自律的に動くことと、分からないことを勝手に決めることは別だからです。
5-3. 実行Agentには、接続済みのToolだけを渡す
タスクを実行する段階で、Agentは利用者が接続済みのSlackおよびMCPサービスのツール一覧を取得します。未接続のサービスや認証情報そのものにはアクセスできません。
Agentは与えられたツールの中から、タスクに必要なものだけを選んで呼び出します。接続済みツールがない場合、調査が必要なタスクではWeb検索を利用します。
AIに自由度を与える一方で、その外側にはアプリケーション側の制約を置くようにしています。
6. AIが失敗しても仕事を続けられるようにする
6-1. AI処理を通常のRequestから切り離す
AIや外部APIを使う処理は、通常のAPI Requestより時間がかかり、失敗する可能性も高くなります。
LLMのTimeoutや外部APIの一時的なエラーが発生したときに、最初からすべてやり直す構成にはしたくありませんでした。
そのため、入力の受付と保存はCloudflare Workersで行い、タスクと判定された後のTask UnderstandingやAI実行はCloudflare Workflowsへ切り出しています。
入力を受け取るAPIは、Task UnderstandingやAI実行の完了を待ちません。その後の処理はWorkflow側で進みます。
6-2. Retryで同じ操作を2回しない
外部Toolを使うと、単純なRetryでは危険なケースがあります。
たとえばSlackへの投稿に成功したものの、その直後にWorkflowが失敗したとします。そのまま同じ処理を最初からやり直すと、同じ投稿を2回行ってしまう可能性があります。
Optioでは、どこまで処理が成功したかをBackend側で記録し、同じタスク・ツール・引数の組み合わせによる完了済み操作を再実行しないようにしています。
AIに「前に実行したか覚えておいて」と任せるのではなく、実行状態はアプリケーション側で管理するという考え方です。
データ構造そのものを複雑に説明するより、ここでは「途中まで成功した処理を記録して、安全に続きを実行できるようにしている」という点を重視しています。
6-3. CredentialはAgentへ渡さない
SlackやMCPの認証情報はBackend側で暗号化して管理しています。
AgentへCredentialそのものを渡すのではなく、Agentからは接続済みのサービスが提供するToolだけを利用できるようにしています。
「危険な操作をしないでください」とPromptだけで制御するのではなく、認証情報をモデルの入力へ含めず、外部操作はBackendが仲介する構成を優先しました。
7. MVPで絞ったことと今後
7-1. 今回は一連の体験を通すことを優先した
今回のMVPでは、入力元をVoiceとSlackの2つに限定しました。
AIが主に実行する仕事も、調査、要約、情報整理、文章作成、下書き作成など、比較的AIと相性のよいものを中心にしています。
何でもできるAgentを作るより、コミュニケーションの中で仕事が発生してから、人がもう一度AIへ依頼し直さなくても完了へ向かって進むという体験を一本通すことを優先しました。
7-2. まだ難しい部分もある
Task Detectionはまだ完璧ではありません。
「これやっておいた方がいいよね」のように、相談なのか依頼なのか曖昧な発言もあります。
Voiceでは、周囲の音や固有名詞の文字起こしミスなどもタスク理解に影響します。
また、人がタスクを登録しなくてよいという体験は、検出精度が低ければ、逆に確認作業を増やしてしまいます。
この部分は、実際の利用を通して改善していきたいところです。
7-3. 専用デバイスでもっと自然に拾いたい
将来的には、専用のマイクデバイスを使い、PCを開いていない場面でも日常の会話から仕事を拾える形を考えています。
現在はDesktop Appが入口ですが、専用デバイスになれば、会議室や移動中に生まれた仕事も自然に取り込めます。
そうなれば、タスク管理アプリを開かないだけでなく、Optioへ入力する操作自体を意識しない状態に近づけます。
一方で、常時利用するデバイスだからこそ、録音状態の可視化や明示的な停止、生音声を保存しないことなど、プライバシー面の設計はさらに重要になります。
7-4. 外部Agentにも仕事を任せたい
もう一つ考えているのが、外部Agentへのタスク委譲です。
将来的には、Optio自身ですべての仕事を処理する必要はないと考えています。
調査、コーディング、デザインなど、それぞれを得意とするAgentが存在するなら、Optioが仕事の内容を理解し、適切な実行先へ渡す形です。
Optioは「何でも自分でできるAgent」ではなく、仕事を見つけ、理解し、誰に任せるか判断し、完了まで前へ進める存在にしていきたいと考えています。
8. まとめ
Optioを作る中で重要だったのは、「AIに何をさせるか」だけではありませんでした。
どこからをTaskと呼ぶのか。どの段階で人へ戻すのか。どの判断をJEVへ任せるのか。どこから生成AIを使うのか。外部Toolをどのように呼び出すのか。失敗したとき、どこから再開するのか。
こうしたAgentの周囲にある境界の設計が、自律的に仕事を進めるためには重要でした。
すべてを一つの大きなAgentへ任せるのではなく、判断、理解、実行を役割ごとに分け、認証情報はモデルへ渡さず、必要な外部操作だけをBackend経由で実行する形にしています。
最終的に実現したい状態はシンプルです。
-
ユーザーは普段通り話して、Slackを使う。
-
その裏側で仕事が見つかり、実行できるものは進んでいく。
-
将来的には、Optio自身で対応できない仕事も、適切なAgentや人へ渡していく。
人がタスク管理を意識しなくても、仕事が前に進んでいる。
Optioでは、そんな状態を目指しています。