AIエージェントのPoCを完了させたけど、ホントはもっとスマートにしたかった話

THE N=1 STORIES　不確実な事業環境を突破した、成長企業6社独自のエンジニアリング
https://elementstech.connpass.com/event/383157/

Transcript

1. 　 AIエージェントのPoCを完了させたけど、 ホントはもっとスマートにしたかった話 THE N=1 STORIES 2026年02月25日 株式会社TOKIUM VPoE 橘高 俊
2. どんなことを話すの？ 2 今回のテーマ「THE N=1 STORIES」 AIエージェントのPoCに挑んだ経験から得た、3つの教訓と未来への考察 • 突然AIエージェントの開発を任されたら、何から始めるか • 「正しい遠回り」と「無駄な遠回り」の違いは何だったのか • 「AI時代に手札を増やす」ことの重要性とは • 技術の土台を理解することが、なぜ近道になるのか • 新しい技術に逆張りせず、まず触ることの大切さとは AIエージェントPoCの実体験から何を学んだのか？ これからエンジニアの仕事はどう変わっていくのか？ 「実装の職人芸」から「信頼性の経済学」への転換とは？
3. Contents 1. 自己紹介 & 会社紹介 2. AIエージェントの PoC 2.1. 当時の開発状況と遠回り 3. 3つの教訓 3.1. 01 手札を増やす 3.2. 02 土台を理解する 3.3. 03 技術に逆張りしない 4. これから先のエンジニア像 4.1. AIに委ねる時代とエンジニアの仕事の変化 3
4. 自己紹介 4 自己紹介 & 会社紹介 経歴 in TOKIUM 2017年　WebエンジニアとしてTOKIUM に入社（社員14人） 2019年　データ連携基盤チームをリーダーとして立ち上げ 2020年　改善チーム（SRE + CRE）へ異動 2021年　CREチームをリーダーとして立ち上げ 2023年　TOKIUM 初のEMとして複数チームのマネジメントを経験 2024年　開発部長としてエンジニアリング組織の成長を牽引 2025年　VPoE として全社におけるエンジニア採用、育成をリード @xi_kax | いかねこ 橘高　俊 Kittaka　Shun
5. 会社紹介 5 自己紹介 & 会社紹介 会社名 設立日 所在地 従業員数 代表取締役 株式会社TOKIUM 2012年 6月 26日 東京都中央区銀座6-18-2 野村不動産銀座ビル 12F 約240名 (2025年11月、正社員のみ) 黒﨑 賢一 TOKIUMの志 未来へつながる時を生む
6. サービス紹介（SaaS） 6 自己紹介 & 会社紹介 創業以来、10年以上一貫して支出にまつわるサービスを提供。 TOKIUMシリーズは直近5年間で導入社数が6倍以上増加し、2025年11月末には3,000社を超える。 2012年6月 創業 2016年2月 「TOKIUM経費精算」リリース 2020年9月 「TOKIUMインボイス」リリース 2022年1月 「TOKIUM電子帳簿保存」リリース 2024年6月 「TOKIUM契約管理」リリース 2025年1月 「TOKIUM請求書発行」リリース 累計導入社数 3,000社を突破 ※25/11末時点
7. サービス紹介（経理AIエージェント） 7 自己紹介 & 会社紹介 2025年7月より「経理AIエージェント」サービス提供を開始。 AIとプロスタッフが連携し、経理業務の自動化を推進するサービスとして拡大中。 2025年7月 「TOKIUM AI出張手配」リリース 「TOKIUM AI経費承認」リリース 「TOKIUM AIヘルプデスク」リリース 「TOKIUM AI経費監査」リリース 「TOKIUM AI新リース判定」リリース 2025年8月 「TOKIUM AI請求照合」リリース 2025年9月 「TOKIUM AI明細入力」リリース
8. AIエージェントの PoC ~どんな形で始まったのか~ 8
9. 9 突然の依頼 2025年5⽉、前触れなくAIエージェントのPoC開発を依頼される → これがTOKIUMのAIエージェントのはじまりとなった
10. 10 突然のPoC完⾛ ※画像はPoC段階のキャプチャです PJ 発足！ エージェント開発が決まる １日目 PoC用アプリの開発が始まる ２日目 SSEでのWeb検索エージェント実装完了 ３日目 チャットUIについて大枠が完成 ４日目 概ねPoC用のアプリが完成 ５日目 メンバー増強、本格的に開発を開始 DEMO 2025年6⽉23⽇、AIエージェントの開発ロードマップを公開 ⽀出管理領域に関連するAIエージェントの複数体提供を予定！
11. 3つの教訓 ~完⾛した感想と得られたもの~ 11
12. 12 当時の⾃分の開発状況 AI開発初心者 Devin を使い始めたばかりの時期 AI を使った開発プロセスは まだ確立できていなかった パワーで押し切る ハッカソンのように泥臭くやった わからないことをとにかく調べて イチから実装を始めていた 正解を知らない AIエージェント開発の「正解」が 誰にもわからない状態で 既存の知識だけでトライしていた 手探りで走り続けた結果、今思えば不要な遠回りをしていたなぁと気づく
13. 遠回りしていた 13 ツールを使うことでいっぱいいっぱいになっていた → もっと先行して AI を業務に使っていればよかった わからないことをイチから調べて泥臭くやっていた → もっと 設計パターンの引き出し を持っておくべきだった 既存の知識だけで正解を手探りし続けていた → もっと インフラなどの基礎 を理解しておくべきだった AI開発初心者 パワーで押し切る 正解を知らない なんとかPoCを乗り越えたから勲章のようになっているが、これらは「しくじり」の原因になりえた。 これから先、AI が発達した先も生き残るためにも使える考え方に昇華したうえで得られた教訓を伝えたい。
14. 14 3つの教訓 01 ⼿札を増やす アーキテクチャを学び、 AIによるコードをどこまでコントロール可能にするかを決める 02 ⼟台を理解する 不変の基礎を学ぶ。 AIに確実に安⼼して委譲できる領域を増やす。 03 技術に逆張りしない AIに対して懐疑的だった分、スタートが遅れた。 逆張りの意味はほとんどないどころかマイナスだった。 03 逆張りしない マインドセット 02 土台を理解する インフラの知識 01 手札を増やす 設計力
15. 15 01 ⼿札を増やす AIの成果物に対して「それだよ！」と言えるヒット率を上げていく この「ヒット率」がAIに対して安心して委譲できる量になる 手札（知っているアーキテクチャ）の数が、AIをコントロール下に置きつつ委譲できる範囲になる 手札が少ない場合 ✍ 全部自分で書き直す or 手札が多い場合 まだ理解できてないコード 人間 + AI補助 理解が曖昧なコード AI + 人間レビュー 未言語化だが理解済みコード AI主導 定型コード AI自動生成 ← AI に委ねる 人間がコントロール → 理解して任せる領域を広げていく 🤖 AIコードをそのまま受け入れる
16. 16 02 ⼟台を理解する AIへ「主権を正しく手放す」ために「不変の基礎」を学ぶ。 AI に置き換えられる速度も早いが、変わらないからこそ安心して任せられるエリアが確定で増える。 AIツール・フレームワーク Cursor, Cline, LangChain … 設計パターン・アーキテクチャ API設計, マイクロサービス, CI/CD … ネットワーク・OS・セキュリティ TCP/IP, Linux, 認証・認可 … コンピュータサイエンスの基礎 データ構造, アルゴリズム, DB … ⟵ 変化が激しい ⟵ 不変 一度学べば ずっと使える AIに任せる エリア → AIに任せる エリア → AIに任せる エリア → AIに任せ る エリア → プロダクト仕様 市場変化, 要求変化…
17. 17 03 技術に逆張りしない 逆張りマインドが生む悪循環を断ち切る。 ミーハーだと思われようが、ノーリスクハイリターンなのでとりあえず流行にのった方が良い。 まだ使えないと 懐疑的になる 距離を置いて 触らない 周囲に遅れをとる 焦って 効率が落ちる 悪循環 まず触る 判断はその後でいい 失敗例を探す 未知の技術に 対する不安 💡 学習効果（Learning Effects） 同じ操作を繰り返すほど熟練度が上がりコストが下がるた め、新しい学習に切り替えるインセンティブが低下する。 — Organizational Path Dependence: Opening the Black Box 意識的に学習効果によって発生する引力から抜け出す。 組織的にはこれが存在することを認識し、壊すインセンティブを設ける。
18. これから先 ~同じ轍を踏まないよう、未来を想像する~ 18
19. 19 AIに委ねる時代は加速するか AIコード生成が高速化によって、実装前後の「人間の介在」がボトルネックになっている。 仕様策定 リリース 実装 レビュー 設計 ・AI の恩恵を最も先に享受したのは「実装」フェーズ 　・実装の多くは AI によって行われている（いずれ 100% になる） ・実装の前後に人間の介在する余地が残っている 　・設計時に、人間は「何」を設計するのか？ 　・レビュー時に、人間は「何」をレビューするのか？ 　　→ パイプラインの多くは実装後の「レビューフェーズ」で詰まっている
20. 20 AIに何をどこまで委ねるか 「人間がレビューしているから品質が保たれている」 — そもそも、これまでどういった品質が保たれていたのか？ 現状の事実 人間のレビューも完璧ではない 見落とし・属人化・スピード限界 新しいアプローチ AIの思考プロセスごと記録・検証 レビューそのものを再定義する動き Entire.io AIの思考プロセスごと記録する 「AIネイティブ版バージョン管理」 Cognition（Devin Review） コード生成ではなくレビューこそ ボトルネックである 「実装をAIが補助する」という前提が見直されたのが 2025年。 レビューの前提そのものを問い直し、 AIはレビューを補助するものではなくなる年になる。
21. 21 エンジニアの仕事はどう変化するのか 「実装・レビュー」がなくなり、「実装の職人芸」から「信頼性の経済学」へ 振る舞いを設計する システムの「振る舞い」を定義する AIが生成するコードの品質ではなく、 システムがどういった価値をお客様へ届 けるのかという「振る舞い」を人間が設 計する時代へ。 考えるべき課題 データ構造・品質・可用性などのベストエ フォートとして包みこまれていた概念が露出 し、正式に合意する必要がでてくるのではない か SLI/Oの適正値を保証する 事後検知の仕組みで品質を守る コードレビューではなく、SLI/Oベース の 品質保証が中心になる。「動いている か」ではなく「約束を守れているか」。 考えるべき課題 単なる「稼働率」から「タスク完了率・正確 性」へ指標が進化したときに、何をもって「振 る舞いどおりである」と証明するのか 信頼性のコスト判断 99.9…%を増やすコストと効果を判断す る いよいよビジネスドメインの理解が不可 欠に。どこまで信頼性に投資するかは 技術ではなく経営判断になる。 考えるべき課題 SLI/O に対してエラーバジェットをどうするの か。SaaSにおいて統一的な品質を提供する場 合の費用対効果をどう考えるのか
22. 少しだけ宣伝 22 LTイベントやります🔥 🍣第3回 寿司ときLTナイト🍣 〜 エンジニア×PdM 越境のリアルな本⾳を語るLT会 〜 03/11(⽔) 19:30〜 @TOKIUM東銀座オフィス（東銀座駅徒歩3分）
23. 23 🤝 SNS はこちら！ 参加してるイベントの実況だったり、登壇するイベントだったり、 その準備（ギリギリ） の様子だったりを雑多につぶやく Twitter アカウント。 長文はほぼ書かずに短文中心で、古のつぶやきスタイルを貫く。
24. Appendix: 参考⽂献 組織慣性 [1] Organizational Path Dependence: Opening the Black Box https://journals.aom.org/doi/10.5465/amr.34.4.zok689 AIネイティブ開発ツール [2] Entire.io — AIネイティブ版バージョン管理プラットフォーム https://entire.io/home [3] Cognition — Devin Review: コードレビューのボトルネックを解消するAIツール https://cognition.ai/blog/devin-review SLA‧信頼性エンジニアリング [4] The Agentic SLA: Moving from "Uptime" to "Outcome" in the Age of AI (2026) https://dohost.us/.../the-agentic-sla-moving-from-uptime-to-outcome-in-the-age-of-ai/ [5] Data Contracts: The New SLA for Reliable AI, Analytics & CRM https://petronellatech.com/blog/data-contracts-the-new-sla-for-reliable-ai-analytics-crm/ [6] Unlocking the value of AI in software development — McKinsey https://www.mckinsey.com/.../unlocking-the-value-of-ai-in-software-development