Beyond the Hackathon — How We Built the Backlog AI Assistant

GDGoC Japan Hackathon 2026 で発表したセッションです。2023年の 社内ハッカソンから始まり、Backlog AIアシスタントを正式リリースするまでに乗り越えた5つのチャレンジ（セキュリティ・信頼性・コスト管理・法務・OSS共創）についてお話ししました。「動くもの」を「使われるもの」にするためのリアルな経験を共有します。

Transcript

1. ハッカソンの "その先" へ — Backlog AIアシスタントができるまで — 2026.03.22 GDGoC Japan Hackathon Speaker : Yuichi Watanabe @Nulab Inc.
2. 自己紹介 渡邉 祐一 / Yuichi Watanabe Nulab: Principal Engineer / AI Integration Unit Lead X: @vvvatanabe GitHub: @vvatanabe 業務で使うOSSへの貢献を大切にしています 自己紹介 & ヌーラボ紹介
3. 自己紹介 & ヌーラボ紹介
4. 自己紹介 & ヌーラボ紹介
5. 2023年 — 業界全体の変革 2023年、ChatGPTが爆発的に広まった。 Notion、Asana、Atlassian…競合が次々とAI機能を出す中、Backlogにはまだ何もなかった。 社内にも 「このままでは置いていかれる」 という空気が広がっていた。 「動くもの」を作る
6. Try Firstで動く 当時リードを務めていたBacklogのGitホスティングチームで、まずやってみようの精神でチ ーム内ハッカソンを決行。 「動くもの」を作る
7. ハッカソンからAI要約リリースへ チーム内ハッカソン → プロトタイプを複数作成 課題作成アシスタント / 課題コメントまとめ / Chrome拡張 / Chat Bot AI要約のコアライブラリにgo-openaiを採用 コントリビュートを通じてLLM APIを深く理解 手応えを感じ、CTO・PDMにボトムアップで提案 → 承認 チームの他プロジェクトを一時停止し、OpenAI連携に集中 社内ベータを経て「AI要約」を一般公開 「動くもの」を作る
8. 2025年 — そしてAIエージェントへ AI要約は「最速で出す」ための機能。まだ入口に過ぎなかった。 2025年、Clineをはじめとする コーディングエージェント が業界全体に広がった。 エージェントの関心事を「プログラム」から 「プロジェクト管理」 に向けたらどうか？ 「動くもの」を作る
9. AIエージェントのPoCへ Clineのソースコードを読み解き、エージェントの仕組みを理解 BacklogのプロジェクトデータをAIエージェントに読ませる 実在の「採用サイト制作プロジェクト」をモデルケースに使用 AIが自律的に 情報取得 → 推論 → 行動 を繰り返す（ReActパターン） 「動くもの」を作る
10. PoCの成果物 プロジェクトサマリ 全体像を一瞬で構造化 目標・スコープ・体制・ペルソナまで 月次レポート & KPT 5ヶ月分を自動生成 FAQ 暗黙知を形式知に変換 課題テンプレート プロジェクトの文脈を踏まえた テンプレートを自動作成 「動くもの」を作る
11. PoCの評価 このプロジェクトに参画していたメンバーに成果物をレビューしてもらい、 「非常に妥当性 のある有益なもの」 と評価を得た 「動くもの」を作る
12. ハッカソンから Backlog AIアシスタントへ 年 できごと 2023年 社内ハッカソン → AI要約を本番リリース 2025年 AIエージェントPoC → 「Backlog AIアシスタント」 としてクローズドベータ 2026年 正式リリース すべては社内ハッカソンから始まった。 でも「動くもの」を 「使われるもの」 にするには、チャレンジがあった。 「動くもの」を作る
13. 「動くもの」から「使われるもの」へ — 5つのチャレンジ 「動くもの」を「使われるもの」にするには、新しいチャレンジがある。 PoCの世界 プロダクトの世界 ① セキュリティ 後回し 多層防御 + データ隔離 ② 信頼性 動けばOK スケール + オブザーバビリティ + 障害復旧 ③ コスト管理 気にしない 使った分だけ正確に測る ④ 法務 なし 安心して使える仕組みを法的に整える ⑤ OSS共創 ライブラリを使う ブラックボックスにしない 「使われるもの」にする
14. ① セキュリティ — AIを安全に使わせる 1つの対策では不十分。城壁を何重にも積む。 Prompt Injection への多層防御 システムプロンプトでツール出力を「信頼できない外部入力」と明示 LLMやツールコールのInput/OutputをスキャンしてLLMで検証 データ隔離 テナント・ユーザーの軸でリソースを完全分離。エラーは内部情報をマスクして返却。 フレームワークの戻り値もアプリ側でアサーションし、ライブラリを過信しない 「使われるもの」にする — ① セキュリティ
15. ② 信頼性 — 安定して使い続けられる 防ぐ: Human-in-the-loop 承認フロー 読み取りは自由、書き込みは人間が判断。 AIが書き込み操作を提案したら、ストリーム を一時停止してユーザーの承認を得る 支える: スケール クローズドベータのトラフィック統計からキャパシティプランニングし、正式リリース 前にインフラを増強 「使われるもの」にする — ② 信頼性
16. ② 信頼性 — 安定して使い続けられる 見る: オブザーバビリティ LLM Observability（Datadog）でトークン消費・レイテンシ・ツールコールやステップ 実行などエージェントの動きをトレース 監査ログで「いつ・誰が・何をしたか」の証跡を記録 復旧する: クロスリージョンフォールバック AIモデルの障害時に別リージョンへ自動切替 「使われるもの」にする — ② 信頼性
17. ③ コスト管理 — 使った分だけ正確に測る AIの利用コストは「呼び出し回数」ではなく「トークン数」で決まる。 月次クレジットシステム テナント単位のクォータ: プランに応じた月間利用枠を設定 推論トークンの予算制御: AIの思考量に上限を設けてコストを抑制 超過時の制御: 利用枠超過で利用を制限し、ユーザーに通知 測れないものは管理できない 「使われるもの」にする — ③ コスト管理
18. ④ 法務 — 技術だけでは守れない 技術対策と法的整備の両輪で、ユーザーが安心して使える状態を作る。 条項 内容 AI学習の禁止 入出力データをAIモデルの学習に一切使用しない Prompt Injection禁止 禁止行為として利用規約にも明記 ハルシネーション免責 AI出力の正確性は非保証、自己責任で確認 出力データの権利 著作権は原則として契約者に帰属、商用利用可 クレジット制の根拠 利用枠の設定・制限・追加購入を明文化 技術と法務、両方揃って初めて「使われるもの」になる 「使われるもの」にする — ④ 法務
19. ⑤ OSS共創 — ブラックボックスにしない コアフレームワーク Mastra を採用。コンセプトは素晴らしいが、登場したばかりだった。 現実 どう向き合ったか 進化が速く 破壊的変更が多い リリースノートを追い、影響範囲を先回りで把握 バグや足りない機能がある コードを読んで原因を特定し、PRを送って修正 ドキュメントが追いついていない ソースコードが最も正確なドキュメント フレームワークをブラックボックスにしないこと。 それが「動くもの」を「使われるもの」に昇華させる鍵だった 「使われるもの」にする — ⑤ OSS共創
20. 5つのチャレンジを越えて 自分たちは社内ハッカソンから始まり、これらを越えて Backlog AIアシスタント を「使われ るもの」にできた。 # チャレンジ 越えたこと ① セキュリティ 多層防御とデータ隔離で、AIを安全に使える状態を作った ② 信頼性 承認フロー・スケール・オブザーバビリティ・フォールバックで安定稼働を実現した ③ コスト管理 クレジットシステムでトークン消費を測り、持続可能な運用を作った ④ 法務 利用規約で技術対策を法的に裏付け、ユーザーが安心して使える状態を作った ⑤ OSS共創 フレームワークをブラックボックスにせず、共に育てた まとめ
21. 今日からできること ① 今日作ったものが「使われる」ことを想像してみる 誰に使ってもらう？ そのとき何が足りない？ — その問いが次の一歩になる ② 「動くもの」を世に出してみる 完璧じゃなくていい。公開することで フィードバックが生まれ、次のチャレンジが見え てくる まとめ
22. 「動くもの」を作った経験は、 「使われるもの」を作る力になる。 今日のハッカソンと、未来のプロダクト開発は地続きです。 まとめ
23. ご清聴ありがとうございました 今日「動くもの」を作れたあなたへ ヌーラボで、 「使われるもの」を一緒に作りませんか？ リンク集 「ヌーラバーの話を聞いてみたい」で検索！