こんにちは！ アスクルのユウです！ 普段は商品情報を管理している商品PFの開発・保守をしています。
アスクルでは社内のプロダクトやシステムに愛称をつける文化があります。私たちのチームが担当している商品PFはHelios（ヘリオス）という名前で、そこから派生した社内向け自律進化型AIの名前がヘリオスちゃん（システム名: helios-ai）です。
Jira・Confluence・Backlog・GitHub・Slackの社内情報を横断検索して質問に答えてくれる、社内向けAIエージェントです。今回はヘリオスちゃんがどんなことをできるのか、どんな構成で動いているのか、そして実際の運用で起きたトラブルまで含めて紹介します。
ヘリオスちゃんとは
@helios-chan にSlackからメンションするだけで、社内ドキュメントを横断検索して回答してくれるアシスタントです。
アスクルの商品PFチームが内製していて、こんな場面で使っています。
- 「このエラー、過去に同じ障害あった？」
- 「あのチケットの仕様ってどうなってたっけ」
- 「APIのある処理、どのクラスが担当してたか調べて」
- 「昨日のデプロイ後からNew Relicでエラーが増えてるんだけど調べて」
- 「このコード、修正してPR作っておいて」
単なるQ&Aではなく、コードを読んで・修正して・PRまで作ってくれるのが特徴です。
できること
ヘリオスちゃんは29本のツールを備えていて、LLMが必要なものを自律的に選びながら最大12回まで試行して回答します。ツールはざっくりこんな分類です。
検索・調査系
| ツール | できること |
|---|---|
search_knowledge |
Jira・Confluence・Backlog・Slack 履歴・GitHub Issues/PR を横断検索 |
search_code |
EFS にクローン済みリポジトリを ripgrep で検索（未ヒット時は GitHub Code Search にフォールバック） |
semantic_search_code |
クラス名・ファイルパスが不明なとき、意味ベースでコードを検索 |
search_file_across_repos |
複数リポジトリをまたいでファイル名でファイルを検索 |
search_backlog |
Backlog プロジェクトのチケットを検索 |
fetch_url |
質問文中の URL をリアルタイム取得・要約 |
query_newrelic |
New Relic に NRQL クエリを投げてログメトリクスを調査 |
investigate_nr_alert |
New Relic アラートを受け取り、直近のログを一括調査して整形 |
read_slack_channel |
指定チャンネルの最新メッセージを取得・参照 |
「昨日のエラー調べて」というと、New Relicのログを引いて該当の例外スタックを見つけて答えてくれます。
コード読み取り系
| ツール | できること |
|---|---|
read_file |
EFS のローカルクローン or GitHub API でファイルを指定行範囲読み込み |
read_files |
複数ファイルをまとめて読み込み |
get_file_outline |
巨大ファイルの構造（クラスメソッド一覧）を先に確認 |
get_repo_structure |
リポジトリのディレクトリツリーを取得 |
find_file |
ファイル名でリポジトリ内を検索 |
list_files |
ディレクトリ内のファイル一覧を取得 |
grep_file |
ファイル内を正規表現で検索 |
find_implementations |
インタフェースの実装クラスを横断検索 |
find_usages |
クラスメソッドの使用箇所を横断検索 |
git_log |
ファイルの変更履歴を確認 |
コード操作系
| ツール | できること |
|---|---|
write_file |
ファイルの新規作成・上書き |
patch_file |
既存ファイルの部分修正（EFS の /work セッション内で作業） |
commit_and_push |
変更をコミットプッシュ |
run_command |
シェルコマンドを実行（テスト実行など） |
コードを読んで → 修正して → コミットプッシュまで一気にやってくれます。
アクション系
| ツール | できること |
|---|---|
create_github_pr |
GitHub の Pull Request を作成 |
close_github_pr |
PR をクローズ |
get_github_pr_comments |
PR のレビューコメントを取得 |
get_github_pr_checks |
PR の CI 結果を確認 |
add_jira_comment |
Jira チケットにコメントを追加 |
ask_clarification |
追加情報が必要なとき、ユーザに質問を投げる |
「PR作っておいて」の一言でブランチを切ってコードを書いてPRを出してくれます。対話的に指示していくとPRのレビュー指摘を確認して返答まで行います。
タスク管理系
| ツール | できること |
|---|---|
create_task |
複数ターンにわたる作業をタスクとして記録 |
update_task |
作業進捗・メモを更新（EFS /cache に永続化） |
list_tasks |
過去のタスク一覧を参照 |
再起動後も「前回の続きから」再開できます。未完了のタスクはAIが起動時に読み込む指示文へ自動で組み込まれるため、ヘリオスちゃんは再起動しても作業の途中から続けられます。
ヘリオスちゃんが「育つ」仕組み
ヘリオスちゃんには、使うほど賢くなるための仕組みが組み込まれています。
フィードバックで学ぶ
回答の末尾に「正しければ 👍、間違いなら 👎 を押してください」というメッセージが付きます。フィードバックを蓄積することで、回答精度の傾向を週次で分析しています。
また、30分以内に同じユーザが似た質問を再投稿した場合は「前回の回答が不満足だった」と自動判定する機能もあります。
知識ギャップを自動検知してチームに質問する
自分（ヘリオスちゃん）が低い確信度で回答した質問を検知すると、専用チャンネルに「この質問、誰か知っている？」と自動投稿します。
チームメンバーがスレッドで答えてくれると、その回答を知識ベースに取り込んで次回から自分で答えられるようになります。
ユーザごとに回答をパーソナライズする
会話から担当システム、環境（dev/prod）、Jiraプロジェクト、技術的な関心領域を自動抽出してQdrantに長期記憶します。次回の回答時にシステムプロンプトへ注入されるため、同じチームのメンバーでも回答の視点が少しずつ違ってきます。
指示文を自分で書き直して PR を出す
毎週日曜、1週間のギャップログとフィードバックスコアを分析して、自分への指示文を書き直す PR を自動で作成します。
[毎週日曜 01:00] ギャップログ・スコア履歴を分析 → LLM が改善案を生成 → コードを修正 → PR 作成（bot/auto-improve-xxxx ブランチ） → Slack に通知
人間がレビューして良さそうならmergeするだけです。ヘリオスちゃんが自分で自分を改善しに来ます。
週次サマリーを Slack に投稿する
毎週月曜に、先週の回答精度・ギャップ件数・フィードバック傾向をまとめたサマリーをSlackに自動投稿します。
放置 PR をリマインドする
毎週月曜、レビュー待ちで放置されているPRを検知して担当者にSlackでリマインドを飛ばします。
技術構成
システム全体像
アーキテクチャ（回答フロー）
あなた │ @helios-chan メンション ▼ Slack Bot（Socket Mode） │ ├─① :eyes: リアクションで「受信確認」 ├─② 処理中はツールに応じてリアクション切替 │ :mag: 検索中 / :pencil: コード編集中 / :bar_chart: NR調査中 ... │ ▼ Agent（tool calling, 最大 12 反復） │ ├─ search_knowledge → Qdrant（ベクトル検索） ├─ search_code → EFS ripgrep → GitHub Code Search（フォールバック） ├─ semantic_search_code → 意味ベースコード検索 ├─ query_newrelic / investigate_nr_alert → New Relic 調査 ├─ read_file / get_file_outline / find_implementations → コード解析 ├─ patch_file / write_file → EFS（/work）にセッションを作成して編集 ├─ commit_and_push → GitHub API ├─ create_github_pr → GitHub API └─ create_task / update_task / list_tasks → EFS（/cache）永続化 │ └─③ :white_check_mark: で完了
インフラ構成
すべてAWSのECS（Fargate）上で動いています。
| コンテナ | 役割 |
|---|---|
helios-ai-bot |
Slack からのメンションを受け取って回答する |
helios-ai-scheduler |
毎日ドキュメントを取り込み・週次の自己改善を実行する |
helios-ai-qdrant |
ベクトルDB（Qdrant）を常時起動 |
ドキュメントのベクトル化データ、Git cloneキャッシュ、コード変更用の作業領域を、EFSの4マウントポイント（qdrant-storage/repos/cache/work）に永続化しています。インフラの管理はTerraform + Atlantisで行っています。
定期学習スケジュール
| タイミング | 内容 |
|---|---|
| 毎日 02:30 | Git clone/pull（リポジトリの最新を取得） |
| 毎日 03:00 | 差分取り込み（Jira・Confluence・Slack・GitHub・Backlog） |
| 毎週月曜 02:00 | フルリインデックス（GitHub 全量） |
| 30 分ごと | PR レビューコメントチェック、自動返信 |
| 毎日 00:30 | スコア異常検知（急に精度が下がっていないか） |
| 毎週月曜 00:00 | 週次サマリー投稿 |
| 毎週月曜 00:10 | 放置 PR リマインド |
| 毎週日曜 01:00 | プロンプト改善提案の分析・PR 作成 |
| 毎週日曜 01:30 | 自動で指示文を書き直す PR 作成 |
運用の中で起きたトラブル
（1）「昨日18時」が1年前の日付として解釈される
私: 「昨日18時のログを調べてほしい」 → ヘリオスちゃんの認識: 「2025-06-13 18:00」（実際は 2026-03-26）
LLMは自分の学習データを基に日付を推測するため、現在日時との感覚がズレます。対処として、ヘリオスちゃんがメッセージを受け取るたびに、現在のJST日時を冒頭へ自動付与するようにしました。
from datetime import datetime from zoneinfo import ZoneInfo JST = ZoneInfo("Asia/Tokyo") _WEEKDAYS_JA = ["月", "火", "水", "木", "金", "土", "日"] _now = datetime.now(JST) _now_str = f"{_now:%Y-%m-%d %H:%M} JST (曜日: {_WEEKDAYS_JA[_now.weekday()]})" question_with_time = f"[現在日時: {_now_str}]\n\n{question}"
（2）「よろしく」と返すと前回の分析を再実行してしまう
ヘリオスちゃんが「件数レベルで分析しましょうか？」と提案したあと、「よろしく」と返すと的外れな回答をするケースがありました。
原因はSlackの fallback_text フィールド（スレッド表示用のテキスト）を200文字に切り詰めていたため、次のターンでLLMが「前回何を提案したか」を文脈として読めなくなっていたことでした。切り詰めをやめてフル回答を保存するようにして解決しました。
（3）ギャップ投稿が短すぎてチームが背景を理解できない
「New Relicのログも見てもらえますか？」という一行だけ転送されても、それが何の質問に対するものかチームには分かりません。ヘリオスちゃんが試みた回答（「〇〇を調べましたが確信度が低い状態です。背景：...」）を一緒に投稿するように改善しました。
（4）検索で結果が見つかっても質問の趣旨と違う回答が返ってくる
検索系ツールはヒットしているのに、回答が要点を外れるケースがありました。「最新のデプロイ後にエラーが増えた」と質問したときに、内容的に関係はあるが別の障害の事例を持ってきて、「以前こんな障害がありました」と答えることがあります。
原因はクエリの表現が近かった別ドキュメントがベクトル検索で上位に来てしまうことです。「新しい」と「関連度が高い」が必ずしも一致しないことがおわかりいただけるかと思います。更新日時や極性のスコアを加味する仕組みを検討中です。
（5）ツールを何度も呼び出して迂回する
最大12回まで試行する設計になっていますが、調査手順の工夫が不十分なときに同じツールを繰り返し呼び出しながら迂回するケースがあります。たとえば search_knowledge → 詳細確認のため read_file → また search_knowledge … と大量のツールコールが発生することがあり、回答に数十秒かかることがあります。調査ステップを整理してシステムプロンプトで優先順位を明確にすることで少しずつ改善させています。
現状の課題
回答精度はまだ波がある
ベクトル検索のヒット精度がクエリの書き方に左右されやすく、社内用語や略称が絡むと見つけられないケースがあります。ギャップ学習の仕組みで少しずつ改善中ですが、まだ道半ばです。
知識ベースの鮮度管理
Slackの過去チャンネルや古いConfluenceページが大量にインデックスされているため、古い情報が新しい情報より先に返ってくることがあります。ドキュメントの更新日時で重み付けする仕組みを検討中です。
コスト
LLM APIへのAPIコールが蓄積すると費用がかかります。頻繁に同じ質問が来る場合のキャッシュ戦略や、軽量なモデルへの切り替えを考えています。
今後の展望
現状のヘリオスちゃんは「呼ばれたら答える」受動的なAIですが、今後はヘリオスちゃんが自分から動く方向に進化させていきたいと思っています。
Slack を定期的に巡回して気づきをアドバイスする
現在はメンションされたときだけ動きますが、監視対象のチャンネルを定期的に読み回って、気になる話題や懸念点をヘリオスちゃん自身から投稿する仕組みを考えています。たとえば「このエラーログ、1週間前に同じパターンがありましたよ」とか「このJiraチケット、関連する先行事例がありそうです」といった形で、呼ばれる前に気づきを提供できるようにしたいです。
ただし、あまり頻繁に割り込むとノイズになるため、自律的に「この話題は言及する価値がある」と判断できる精度が必要です。現状の回答精度の波という課題が解消できていないと、見当外れのアドバイスを連発してしまう恐れがあります。
自律的に PR を作成する
現在もユーザからの指示を受けてPRを作成できますが、将来的には「定期的なリファクタリング候補の検出」「依存ライブラリの脆弱性アップデート」「ドキュメントの陳腕化検知と修正PR」など、誰かに言われなくても定期的に PR を出してくれる動きを目指しています。
指示文を自動で書き直してPRを作る仕組みはすでにありますが、これを対象リポジトリに拡張するイメージです。
課題としては、コードベースへの理解精度と変更の影響範囲を適切に判断できるかどうかです。誤ったPRを大量に作られると、レビューコストがかえって増えてしまいます。まずは修正範囲が小さく、影響が限定的なものから試していく予定です。
まとめ
- ヘリオスちゃんはJira・Confluence・GitHub・New Relicなどを横断検索して、コードの修正・PR作成まで自律的に実行できる社内AIエージェント
- ツールは29本。検索・コード読み取り・コード操作・タスク管理・アクションと幅広くカバー
- 使うほど育つ仕組み（フィードバック学習・ギャップ自動質問・プロンプト自己改善）が組み込まれている
- 定期タスクが多く、スケジューラーの安定運用が意外と大変
- 小さなバグ（日時誤解釈・文脈の切り詰め・EFSマウント漏れ）が積み重なると動作がおかしくなる
まだまだ改善中ですが、チームの中で少しずつ頼られる存在になってきています。また進捗があったら書きます。
なお、ヘリオスちゃんの実装および本記事の作成は、すべて GitHub Copilot と一緒に行いました。
