指示を待つAIから、作業に口を出すAIへ：AI秘書のプロトタイプ

TL;DR

• ジュニアエンジニアには「詰まっているときに相談が遅れる」という課題が残っています。これは、AIがより賢くなっても自然には解決しません。
• そこで、作業文脈をもとに現在の作業を推定し、予定時間を超えたらSlack DMで通知する「AI秘書」のPOCを作りました。
• Jiraチケット単位での作業特定はかなり実用域にある一方で、その内側にある「仮想タスク」への分解はまだ検証中です。

課題：新卒が陥りがちな「相談の遅れ」

初めまして。2026年新卒のI・Aです。

Claude Codeなどのコーディングエージェントのおかげで、実装・調査・バグ修正といった「明示的に頼んだ作業」は、高い精度でAIに任せられるようになりました。

一方で、ジュニアエンジニアとして開発していると、まだ人間側に残っている課題があります。詰まっているときに、相談が遅れることです。人に聞けば数分で解決するような問題に何時間も費やしてしまったり、目の前の作業に集中しすぎて報告や相談が後回しになったりするのは、私に限らずジュニアエンジニアに共通する経験ではないでしょうか。

これは、AIがより賢くなっても自然には解決しません。頼んだ作業の精度がどれだけ上がっても、「相談する・切り上げる」という判断は本人に残ったままだからです。

必要なのは、明示的な指示を待つだけでなく、作業文脈を見て「そろそろ相談した方がよいかもしれない」と口を出してくれる仕組みです。

この記事では、この仕組みを「AI秘書」と呼び、その構想とPOCを作る中で分かったことを紹介します。完成したプロダクトの紹介ではなく、「作業に口を出すAI」がどこまでできて、どこからが難しいのかを整理する記事です。

作ったもの：「AI秘書」

そこで今回は、作業者の周辺文脈を集めて現在の作業を推定し、予定時間を超えていたらSlack DMで知らせるAI秘書のPOCを作りました。目指しているのは、時間を正確に記録することではなく、相談や切り上げのきっかけを本人に届けることです。

全体像

左側が、AI秘書の参照するデータソースです。Claude Codeのログ、ローカル活動、GitHub、Slack、Google Calendarなどです。

中央では、これらの情報を統合し、15〜30分程度の「判定窓」ごとに作業の流れを組み立てます。そのうえでLLMが、「この作業は既存の仮想タスクのものか、それとも新しいタスク候補か」を判断します（仮想タスクについては次節で説明します）。ただし、LLMに任せるのはこの割当の判断だけです。時間の集計や予定時間超過の判定は、システム側で決定的に計算します。

右側が通知です。予定時間を超えた場合、Slack DMで警告と選択肢を送ります。ユーザーはその通知を見て、予定時間を延長する、判定を補正する、別のタスクとして扱う、といった対応を選べます。

POC全体の流れを簡略化すると、次のようになります。

1. 作業痕跡を集める
        ↓
2. 時刻・Jiraキー・文脈で統合する
        ↓
3. 判定窓ごとの作業の流れにまとめる
        ↓
4. LLMで現在作業を推定する
        ↓
5. 仮想タスクへ割り当てる
        ↓
6. 予定時間と実作業時間を比較する
        ↓
7. 超過していたらSlack DMで通知する

仮想タスクとは

仮想タスクは、JiraチケットやGitHub Issueそのものではありません。予定時間と出口戦略（予定時間を超えたら何をするか。詳しくは後述します）を持たせるための、もう少し小さい作業単位です。

たとえば、1つのJiraチケットの中には複数の作業が含まれます。

Jiraチケット: PROJ-123

その内側:
- backend保存処理修正
- PRコメント対応
- ローカル動作確認
- staging確認
- reviewerへの相談

Jiraチケット単位でも「どの大きな仕事に関係しているか」までは分かります。しかし、相談や切り上げが必要になるのは、多くの場合その内側の作業単位です。そこでAI秘書では、Jiraチケットより小さく、ただし細かすぎない単位を仮想タスクとして扱います。

仮想タスクは現状、作業を始める前に作業者が自分で登録します。登録するときに決めるのは、タスクのタイトル、関連するJiraチケット、予定時間、出口戦略の4つです。LLMが観測から新しいタスク候補を提案することもありますが、未承認の候補として溜まるだけで、作業者が承認するまでは予定時間を持つ管理対象になりません。

今回のPOCでは、判定窓ごとに作業痕跡を集めてLLMで現在の仮想タスクを推定し、予定時間を超えたらSlack DMで通知するところまでを試しました。ただし、仮想タスクをどの粒度で切るべきかはまだ検証中です（詳しくは「できなかったこと」で述べます）。

実行環境・技術要素

AI秘書の本体は、Rustで実装したCLIツールです。ローカルPC（macOS）上で動き、常駐はしません。1回の実行で1つの判定窓（既定15分）を処理するバッチで、検証ではlaunchdから定期起動して動かしています。

データの取得・判定・通知には、次の要素を使っています。

• Claude Codeのログ：~/.claude/projects/<プロジェクトごとのディレクトリ>/ 配下のJSONLファイルを、自作のログ解析ツールで読み取ります。セッションのタイトル、cwd、git branch、ユーザー指示の内容が取れるため、AIエージェント側の作業セグメントはここから作ります。
• ローカル活動：自作の常駐センサー（Rust製）が、前面アプリの切り替えをNSWorkspaceのイベントで、ウィンドウタイトルをAccessibility APIで取得し（5秒間隔の安全網ポーリングを併用）、SQLiteに記録します。focus・AFK・画面ロック・mic（会議中の検出用）などのイベントと、プロセスやブラウザタブなどのスナップショットという形式で残し、AI秘書からはread-onlyで参照します。
• GitHub：Issue/PRやGitHub Projects上のKanbanの状態を取得し、Jiraキー単位の文脈（WorkContext）にまとめて判定の入力に加えます。
• Slack：自分に関係する発言を取得し、同じくWorkContextに取り込みます。
• LLM：Claude Code CLI（検証時点で2.1系）をヘッドレスモード（claude -p）のサブプロセスとして呼び出します。モデルは claude-sonnet-4-6 を指定しています。判定は15分ごとに走るため、コストを抑えられるモデルを既定にしました。出力はJSON Schemaで形式を固定し、ツール実行はすべて無効化しています。
• 通知：Slack Web APIの chat.postMessage で、Bot名義のDMとして送ります。
• 設定と操作：動作設定は、~/.auto-tempo/secretary/config.yaml にYAMLで書きます。判定窓の長さ、業務時間（超過通知はこの範囲内だけ送ります）、通知先、判定に使うモデルなどをここで変更できます。一方、仮想タスクの登録・予定時間の延長・判定の補正は、設定ファイルではなくCLIのサブコマンド（secretary task extend など）で行います。

ユースケース：「AI秘書」の実行例

1チケットの具体例

AI秘書が実際にどう動くのか、1つのJiraチケットを進める場面で追ってみます。

例として、backendの保存処理を修正するチケットPROJ-123を進めているとします。実装のPRはすでに出ていて、いまはreviewerのコメントに対応しているところです。この作業には、あらかじめ仮想タスクを1つ登録してあります。

仮想タスク: PRコメント対応
関連チケット: PROJ-123
予定時間: 45分
出口戦略: 45分を超えたらreviewerにSlackで相談する

作業を進めると、手元の環境には痕跡が自然に残ります。ブラウザでPR画面を開けばウィンドウタイトルにPR番号が入り、Claude Codeに指示を出せばセッションログに指示内容やgit branchが記録されます。AI秘書は15分ごとの判定窓でこれらを集め、Jiraキー・GitHub PR・リポジトリといった手がかり（アンカー）ごとに、同じ作業らしい痕跡のまとまり（これをセグメントと呼びます）へ整理します。この窓では、たとえば次のような入力になります。

判定窓: 2026-06-30 14:00〜14:15

human_segment h0（人間の操作）:
  主アンカー: github_pr: backend#412
  Jiraキー: PROJ-123
  アプリ: Chrome, iTerm2
  証拠: ウィンドウタイトル「Fix save logic · Pull Request #412」など

agent_segment a0（Claude Codeの稼働）:
  セッション: 「PROJ-123 保存処理修正」
  branch: feature/PROJ-123-fix-save
  直近の指示: 「reviewコメントの指摘に対応して」

LLMはこの入力を既存の仮想タスク一覧と突き合わせ、「どのセグメントがどのタスクの作業か」だけを判断します。出力は次のようなJSONです。

{
  "assignments": [
    {
      "segment_id": "h0",
      "target_kind": "existing_task",
      "target_id": "vt1",
      "confidence": 0.92,
      "reason": "PR #412 への操作と PROJ-123 が既存タスク「PRコメント対応」と一致する"
    },
    {
      "segment_id": "a0",
      "target_kind": "existing_task",
      "target_id": "vt1",
      "confidence": 0.9,
      "reason": "同じ branch と Jira キーを指す Claude Code セッションのため同一作業"
    }
  ],
  "new_candidates": []
}

ここから先はLLMではなく、システム側の決定的な処理です。confidenceが低い割当は自動では採用しません。採用した割当結果をもとに「PRコメント対応」の実作業時間を集計し、予定時間と比較します。この窓では人間とagentが同じタスクに向かっているので、時間は二重計上せず15分として加算します（この扱いは後述の工夫点で説明します）。集計した累積は55分になり、予定の45分を超えていたので、Slack DMが届きます。

予定時間を超えました。

task_id: vt1
window: 2026-06-30T14:00

仮想タスク: PRコメント対応
関連: PROJ-123
予定時間: 45分
実作業累積: 55分
出口戦略: 45分を超えたらreviewerにSlackで相談する

補正例:
secretary task extend vt1 --minutes 15 --reason "..."
secretary task list

受け取った私は、事前に決めた出口戦略どおりreviewerに相談するか、「あと15分で終わる」と見込めるなら予定時間を延長して続けます。仮にLLMの判定が間違っていても、この通知を見た時点で気付いて補正できます。

設計上の工夫点

この動きを作るうえで、設計上こだわった点が3つあります。

1. 予定時間だけでなく出口戦略が必要

予定時間を設定するだけでは、通知されても「それでどうするのか」が分かりません。しかも、詰まっているときほど出口は見えなくなっています。作業に没頭していると視野が狭くなり、「誰かに相談する」「分かったことを整理する」「一度切り上げる」といった選択肢を思いつきにくくなるからです。

そこで、詰まってから出口を考えるのではなく、作業を始める前に「予定時間を超えたら何をするか」を決めておくことにしました。これを出口戦略と呼んでいます。

例:
- 45分を超えたら、reviewerにSlackで相談する
- 30分で原因が分からなければ、分かったことをまとめて相談する
- 20分で再現できなければ、再現条件を整理して共有する

こうしておくと、通知は単なる「時間を超えました」ではなく、次の意味を持ちます。

予定時間を超えました。
事前に決めた出口戦略を実行するタイミングです。

今回解きたい課題は「相談の遅れ」なので、出口戦略はAI秘書に欠かせない要素です。

2. LLMには判断だけをさせる

今回の設計では、LLMにすべてを任せていません。任せるのは「これは何の作業か」という文脈の判断だけです。たとえば、PRの閲覧、Slackでのreviewerとのやりとり、Claude Codeへの指示が同じPRに向いていれば、「PRコメント対応」というひとつの作業だと判断する部分です。

一方で、次の処理はLLMに任せません。

LLMに任せないもの:
- 時間計算
- human / agent の重複排除
- 予定時間超過判定
- 通知送信
- 永続化

これらは通常のプログラムで決定的に処理します。LLMは文脈の解釈には柔軟ですが、出力が毎回同じになる保証はないからです。

LLM:
  作業文脈を解釈する
  仮想タスクへ割り当てる
  新規候補を出す

System:
  時間を計算する
  超過を判定する
  通知する
  保存する

こう分けておくと、LLMの判断が多少ぶれても、時間の集計や超過判定はぶれません。LLMを業務ツールに組み込むうえで、この責務分離は効いていると感じています。

3. AIエージェントの稼働時間を扱う必要がある

コーディングエージェントを使う開発は、単純な逐次作業ではありません。人間がPRを確認している間にClaude Codeが別の修正を進めていることもあれば、人間がClaude Codeの出力を見守っているだけの時間もあります。作業時間は「人間が画面を見ていた時間」だけではなく、人間の時間とAIエージェントの稼働時間が並列に流れています。

そのため、AI秘書には並列作業を前提にした時間計算が必要です。同じ仮想タスクに人間とagentが同時に取り組んでいる場合は、二重計上しない方が自然です。

10:00-10:15
human: PRコメント対応
agent: PRコメント対応

→ PRコメント対応は15分

一方で、人間とagentが別の仮想タスクを進めている場合は、それぞれに時間を付けます。

10:00-10:15
human: PR確認
agent: migration方針整理

→ PR確認も15分
→ migration方針整理も15分

これは従来の工数記録というより、「各仮想タスクがどれだけ進行・滞留しているか」を見るための時間計算です。

「AI秘書」で実現できた成果

できたこと：大きな作業の特定

今回のPOCでは、Jiraチケット単位で「どの大きな作業に関係しているか」を特定するところまでは、かなり実用域にあると確認できました。

Claude Codeの履歴やGitHubの情報からは、セッション名、git branch、cwd、Issue/PRといった手がかりが取れます。セッション名やbranch名にはJiraキーが含まれていることが多く、IssueやPRもJiraキーに紐づいています。これらを組み合わせると、「いまどのチケットの作業をしているのか」は機械的にかなり寄せられます。今回のPOCでも、ローカル操作、Claude Code履歴、GitHub/Kanban、SlackをJiraキー単位のWorkContextとして束ねる設計にしました。

できなかったこと：小さな作業の特定

一方で、今回解きたい課題に対しては、それだけでは足りません。相談や切り上げが必要になるのは、多くの場合、Jiraチケット全体ではなくその中の小さな作業単位だからです。そして、このJiraチケットより小さい仮想タスクへの安定した分解が、まだできていません。

1つのJiraチケットの中には、実装、PRコメント対応、ローカル動作確認、仕様確認、reviewerへの相談などが混ざっていて、詰まりが起きるのはたいていこの内側です。

難しいのは粒度です。細かく分けすぎるとノイズになります。Slackを2分確認した、review commentを1件読んだ、localhostを1回開いた、といった行動まで仮想タスクにすると、通知も候補も増えすぎます。かといって粗すぎると、どこで詰まっているかが見えません。「PROJ-123対応」という単位では、実装で詰まっているのか、動作確認で詰まっているのか、仕様確認で詰まっているのかが分からないからです。

AI秘書というと、すべての作業を細かく拾いたくなります。しかし、今回の目的は作業ログの完全性ではなく、詰まりの検出です。そこで、「記録すること」と「予定時間を持つ管理単位にすること」を分けて考えることにしました。短い確認のような作業は、記録には残しつつ、仮想タスクにはしません。

記録する:
- 短いSlack確認
- ブラウザ閲覧
- review comment確認

仮想タスク化する:
- PRコメント対応
- ローカル動作確認
- 仕様確認
- staging確認

Mac上では、前面アプリ、ブラウザ履歴、ウィンドウタイトル、terminal cwd、git branch、入力有無、mic、lockなど、細かいシグナルを取得できます。しかし、取得できるからといって、すべてをタスク化する必要はありません。AI秘書に必要なのは、これらを詰まりの検出に効く粒度へ変換することです。その「効く粒度」がどこにあるのかが、まだ検証できていない部分です。

今後の展望

今後はまず、実際に取り組んだ作業を数日分記録し、仮想タスクの粒度を分析します。見たいのは、次のようなことです。

- どの作業は仮想タスクとして扱うべきか
- どの短い作業は無視してよいか
- 予定時間と出口戦略を持たせる意味がある作業は何か
- 相談や切り上げに本当に効く粒度はどこか

そのうえで、AI秘書が口を出すべきタイミングを検証していきます。将来的には、相談文の下書きや相談相手の推薦、Slackへの半自動投稿なども考えられますが、今回のPOCでは、どの作業に時間を使っているかを把握し、予定時間の超過を知らせるところまでに絞りました。

まとめ

コーディングエージェントによって、明示的に頼んだ作業は任せられるようになりました。それでも、相談すべきタイミングを逃す問題は残ります。この問題に対して、作業文脈から詰まりの可能性に気づき、相談や切り上げを促す仕組みとして「AI秘書」のPOCを作りました。

試して分かったのは、Jiraチケット単位の作業特定はかなりできる一方で、本当に難しいのはその内側にある仮想タスクへの分解だ、ということです。

今後は実作業のログをもとに仮想タスクの粒度を検証し、頼まれた作業をこなすだけでなく、「そろそろ相談した方がよい」と口を出せるAIに近づけていきたいです。

最後に

グループ研究開発本部 次世代システム研究室では、最新のテクノロジーを調査・検証しながらインターネット上の高度なアプリケーション開発を行うエンジニア・アーキテクトを募集しています。募集職種一覧 からご応募をお待ちしています。