こんにちは、ラクス技術広報です。 開発本部では、各部署でのAI活用の取り組みを技術広報がインタビューし、記事としてお届けしています。今回お話を伺ったのは、楽楽請求開発部でバックエンド開発を担当する吉元和仁さんです。 楽楽請求のバックエンドチームは、昨年度の下期から仕様駆動開発（Spec-Driven Development、以下SDD）の導入を進めてきました。掲げた目標は「AIによる実装の完全自動化」です。 半年ほど回してみて、実装そのものは速くなりましたが、速くなったのは個人の作業で、チームとして再利用できる資産は積み上がっていませんでした。 この記事は成功事例の紹介ではありません。SDDを導入して4つの壁に当たり、一部のメンバーがClaude CodeのPlanモードでの開発に戻りはじめ、そこから打ち手を「SDDそのものの改善」から「SDDが回る環境の整備」へ切り替えるまでの、現在進行中の記録です。同じところで詰まっている方に、判断の材料として読んでいただければ幸いです！ なぜ請求のチームが、実装の自動化を目指すのか cc-sddに加えた5つのカスタマイズ それでも残った、4つの壁 品質の再現性 レビューの肥大化 完了基準の不在 プロセスの重厚さ 「Planモードのほうが速い」という声 打ち手を「SDDの改善」から「SDDが回る環境の整備」に変えた レビュー指摘を、次に繰り返さない形に変える 出発点は「指摘がなかなか減らない」だった 生データから知識へ、知識からSKILLへ 「残す指摘」と「残さない指摘」を分けた SKILLへ昇格させる3つの条件 人間に残した仕事は「承認」と「マージ」だけ 配布はPlugin Marketplaceに乗せた 正直に言うと、まだ回しきれていない これから なぜ請求のチームが、実装の自動化を目指すのか 楽楽請求は、請求業務を効率化するクラウドサービスです。請求業務には毎月必ず締めがあり、制度改正への対応も期日が決まっています。顧客の業務が止められない以上、改善を早く届けられるかどうかがそのまま顧客への価値になります。 SDDに取り組み始めたきっかけは2つでした。社内の別チーム（楽楽明細・楽楽自動応対）で先行して成果が出ていると聞いていたこと、そして全社としてAI活用を進める方針が出ていたことです。 フレームワークにはcc-sddを選びました。その理由を吉元さんはこう説明します。 「既存の設計ドキュメントと開発プロセスを作り変えずに導入できること、そして自社の工程やレビュー観点を組み込めること。この2点を最優先に評価し、cc-sddを採用しました。」 一方のcc-sddは、既存のプロダクトコードを起点に整合性を検証する仕組みを持っています。現行のプロセスやドキュメントを大きく作り変えずに導入でき、独自の工程やレビュー観点もSKILLを追加するだけで組み込める。稼働中のサービスに、既存の開発プロセスを活かしたままSDDを入れたいという狙いに、いちばん合っていたといいます。 目標として「実装の完全自動化」を掲げたときのチームの反応を、吉元さんはこう振り返ります。 「反対意見はありませんでしたが、前のめりに聞いてくれるメンバーもいない、という状況でした」 吉元さん自身、AIの進化が伴わなければ達成は難しい目標だと認識していたそうです。それでも掲げたのは、具体的にイメージできる目標を示さなければ、チームが同じ方向を向いて動きにくいと考えたためでした。 cc-sddに加えた5つのカスタマイズ 標準構成のままでは、自社の開発プロセスに乗りませんでした。現在までに加えたカスタマイズは、大きく5つあります。 1. 設計書をレイヤーごとに分割した 標準では設計を1枚の design.md にまとめますが、これをDB設計、ドメイン設計、API設計、その他設計の4ファイルに分けました。レイヤーごとにレビュアーが異なるため、各自が担当領域だけをレビューでき、完成した設計書から順にレビュー依頼を出せます。特に影響範囲の大きいDB設計を早い段階でレビューできるようになったことが、リードタイムの短縮と手戻りコストの抑制につながりました。 2. 工程ごとにプロジェクト固有のルールを読み込ませた 標準はプロダクト概要、技術スタック、ディレクトリ構成の3ファイルのみを前提にしています。これだけでは、命名規則やマイグレーション手順といった自社の規約が設計に反映されません。そこで各工程に、DB設計規約、API設計規約、実装ガイド、テスト実装ガイド、用語集といったルール集を必ず読み込ませるステップを足しました。 3. 大きな機能を親子構成で分割できるようにした 1機能が数か月規模になるとタスクを管理しきれません。大きな機能を要件のまとまりごとに親子構成で分割できるようにして、タスク管理のしやすさと、分業によるリードタイム短縮を両立させました。 4. AI向けと人間向けで設計書を分けた design.md はAIエージェント向けの記述で、人間には読みにくいものです。しかも情報量が増えるとAIコーディングエージェントのコンテキストを圧迫し、生成物の品質が落ちます。そこで design.md はAIコーディングエージェント専用と位置づけ、人間向けにはHTML形式の設計書を別途生成する構成にしました。design.md はコンテキストを圧迫しない分量に抑える必要がありますが、人間しか読まないHTML設計書はその制約から外せます。図や表も使えるため、分量を割いて丁寧に書けます。 これは当初、詳細設計書の補助ツールという位置づけで入れたものでした。ところが開発者からのポジティブなフィードバックが多く、後述するとおり詳細設計レビューが一番のボトルネックになっていたこともあって、開発プロセス本体に組み込むことになりました。現在は詳細設計の担当者が、AIが生成した詳細設計書をレビューするタイミングで、HTML設計書を生成しています。 5. 独自スキルを追加した 仕様の分割、事前調査といった独自スキルを足していき、現在は43スキルを運用しています。 それでも残った、4つの壁 カスタマイズを重ねても、構造的に残る課題が4つありました。 品質の再現性 AIの生成物は確率的で、同じ指示でも実行のたびに違う結果が返ります。壊れているのにチェックが通ったり、通らなかったりする。 たとえばチームではAIによる自動コードレビューを導入していて、レビュー用のSKILLにコーディングルールやガイドラインを記述しています。ところがレビュー結果自体が確率的なため、1回のコードレビューですべての指摘を拾いきれない。ルールを書いたから守られる、という前提が成り立たないわけです。 レビューの肥大化 これは当初の想定と違っていた、と吉元さんは言います。レビューの総時間自体は、実は大きく変わっていませんでした。問題は別のところにありました。 AIが生成する詳細設計書には、コードの断片が埋め込まれることがあります。すると、レビュアーは詳細設計書のレビューに加えて、コードレビューまで同じタイミングで行うことになる。従来は詳細設計フェーズとコードレビュー（PR）フェーズに分かれていた作業が一箇所に集中し、レビューとフィードバックが直列につながってしまいます。結果としてリードタイムが長くなりました。 チーム内からは「これ全部見てたら、コードを見てレビューした方が早いんじゃないか」という声も出ました。 完了基準の不在 設計書の完了基準が決まっていない、という課題もありました。ここでチームは一度失敗しています。 人間による詳細設計書レビューの負担を下げようとして、「詳細設計書にコードを記述しない」「行数を500行に制限する」というルールを設けました。ところがその結果、設計判断に必要な情報が欠落したり、設計情報を聞き慣れない用語で圧縮したり、1行あたりの情報量が増えたりして、かえって認知負荷が高くなってしまったのです。 完了基準は「人がレビューしやすいか」と「AIハーネスとして機能するか」の両方から定義しないと決まりません。片方だけを見て基準を作ると、もう片方が壊れます。 プロセスの重厚さ SDDのプロセスは重いため、小規模なタスクでは個別のツールを直接叩いた方が速い場合があります。 「Planモードのほうが速い」という声 4つの課題が残るなかで、チームからは「Planモードのほうが実装は速い」という声が上がるようになりました。実際にPlanモードで開発しているメンバーもいました。 吉元さんは、これ自体を悪いこととは考えていません。個人の生産性には確かに寄与していたからです。 引っかかったのは別の点でした。 「Planモードは設計内容等のコンテキストがセッション内に閉じてしまうため、規模の大きい開発案件ではスケールしません」 個人単位では生産性が上がる一方で、その成果や進め方が組織全体に展開されず、チームとして再利用できる資産が蓄積されていかない。「組織としてのスケールメリットが得られていない」と判断した決め手はここでした。 チームが目指しているのは「実装を自動化し、人間が上流工程へシフトする」という姿です。そこから逆算すると、Planモードへの回帰による効果は限定的だと感じた、と吉元さんは振り返ります。 打ち手を「SDDの改善」から「SDDが回る環境の整備」に変えた そこで方針を切り替えます。SDDのプロセス自体をいじり続けるのをやめて、それが回るための環境を整える方向に戻る。取り組みは4つです。 取り組み やること 対応する課題 ナレッジ化 ハーネスと暗黙知を体系化し、レビュー負荷を軽減して品質を底上げする レビューの肥大化 出力の安定化 単一のAIに任せず、複数のエージェントが相互に評価し合う仕組みを整備する 品質の再現性 プロセス設計 SDDフレームワークを再定義し、タスクごとの適用基準と詳細設計基準を策定する 完了基準の不在、プロセスの重厚さ 基盤整備 ローカル依存から脱却し、AIエージェントが自律的に並列稼働できる実行基盤を作る 自動化の前提 レビュー指摘を、次に繰り返さない形に変える 出発点は「指摘がなかなか減らない」だった 背景にあったのは、暗黙知が多く、実装レビューでの指摘がなかなか減らないという問題でした。AIに実装やコードレビューを任せるうえでも、暗黙知を形式知にしてAIコーディングエージェントの品質の再現性を高める必要がありました。 取り組んだのが、PRのレビューコメントとIssueから繰り返し出ている指摘を集め、開発ガイドライン（Claude CodeのSKILL）に反映していくパイプラインです。社内リポジトリとして構築しています。 生データから知識へ、知識からSKILLへ 仕組みは3段階で、進むほど情報が絞り込まれます。 集める （fetch）：PRのレビューコメント、Issue、Claude Codeのセッション情報を取得する パターン化して残す （ingest）：繰り返し出ている指摘を、LLM用のWikiに蓄積する ガイドラインへ上げる （promote → 承認 → apply）：条件を満たした指摘をSKILLに反映するPRを作る これを週次で回し、月次で lint をかけて点検しています。 ちなみに、「1.集める」「2.パターン化して残す」「lint」というアイデアは、 Andrej Karpathy氏が「 LLM Wiki 」と呼んでいるパターンを採用しています。 「残す指摘」と「残さない指摘」を分けた 知識層に残すのは、確定した方針やルールがある指摘だけです。却下された指摘、「後続PRで対応」と先送りされたもの、返信がないまま流れたもの、未マージPR上の指摘は残しません。判断に迷うものは、残さない側に倒します。 直した証拠も決めた方針もない指摘をページにすると、実際には守られていないルールを知識として登録してしまうからです。知識層はAIが読む前提の場所なので、守られていないルールが溜まるほど、AIの実装がチームの実態から離れていきます。 SKILLへ昇格させる3つの条件 知識層からSKILLへ上げるときの条件は次の3つです。 反復性 ：同じ指摘が3回以上、かつ指摘者が2名以上 是正実績 ：実際に修正コミットが発生していて、かつ2回以上 障害起因 ：incident / postmortem ラベル付きIssueの再発防止策なら1回で候補 この条件を置いた理由を、吉元さんはこう語ります。 「上がってきた指摘をそのまま採用すると、内容が具体的すぎたり、個人の設計スタンスが反映されたりして、AIのコーディングルールが膨大化し、品質に影響します。複数の指摘があることで、ルール化しにくい暗黙知を抽象化できると考え、この条件を設定しました」 1人の指摘なら個人の好みかもしれない。2人以上から同じ指摘が出ているなら、チームの規範として扱える。ルールが増えすぎて誰も守らなくなる事態を、この線引きで避けようとしています。 人間に残した仕事は「承認」と「マージ」だけ 取得も、抽出も、執筆も、起票もAIが行います。人間に残したのは、承認とマージの2つだけです。 では、なぜ全自動にしなかったのか。 「AIが出力する内容が、まだ承認なしで採用できる品質には至っていないためです」 そう説明したうえで、吉元さんは「LLMの進化に期待」とも付け加えます。現時点では、AIが提案してPRを作るところまでを自動化し、直接pushや自動マージはしません。 配布はPlugin Marketplaceに乗せた 作ったスキルは、別の社内リポジトリをClaude CodeのPlugin Marketplaceとして機能させ、/plugin install で各開発者に配布しています。自動更新を有効にしておくと、セッション開始後にバックグラウンドで最新のスキルを取得し、次にClaude Codeを立ち上げた時点で反映されます。各開発者が手動で更新する必要はありません。 このリポジトリを用意したのは、AI活用の事例を個人に閉じさせず、試して改善効果が得られた内容を共有する文化を作りたかったからでした。ただし全員が共有を始めると、開発プロセスに組み込まれているものとそうでないものの区別がつきにくくなります。そこで、安定運用の tools と試験運用の labs に分けています。 正直に言うと、まだ回しきれていない ここまで紹介してきましたが、現状は道半ばです。 知識層のwikiには現在およそ700件が蓄積されています。一方、SKILLへの昇格は20件程度で、運用が十分に回っているとは言えない状態です。週1で回す設計にしているものの、そのサイクル自体をまだ回しきれていないといいます。 スキル修正提案のPRも大量に来ています。AIが投げたものと人が投げたものが混在した状態で、いまチームで手分けして選別しているところです。 工数削減については、詳細設計と実装の工程を対象に集計を始めており、段階的な削減を目標として置いています。手応えは出はじめているものの、継続して再現できるかはこれからの検証次第だと吉元さんは見ています。 他チームへの横展開にも課題があります。スキルの中にチーム固有のファイルパスやリポジトリパスが多く含まれているため、汎用的に使ってもらえる形にするにはもうひと段階のハードルがあります。 これから 基盤整備については、クラウド環境（Claude Code on the web）上での自動実装には対応済みです。ただし完全な並列実行には至っていません。実行環境の制約でビルドやテストの実行が難しいため、現状は「クラウド環境で実装してPRを作成する、CIでテストを実行する、結果を監視して修正する」という進め方を代替案として採っています。 最後に、同じところで悩んでいるエンジニアへのメッセージを吉元さんに伺いました。 「LLMの進化は速いため、それを見据えて、AI駆動開発の中長期的な戦略を立てるべきだと考えています」 目の前のプロセスを改善し続けても、半年後には前提が変わっているかもしれません。 品質の再現性、レビュー、完了基準、プロセスの重さ。楽楽請求のチームは、この4つを同時に潰す「環境」をいま整えている途中です。 開発本部では、他の部署でのAI活用の取り組みも順次記事にしてお届けしていく予定です。うまくいっていないことも含めて、また共有できればと思います。

こんにちは。『楽楽請求』でフロントエンドを担当しているtakenamiです。 『楽楽請求』では立ち上げ当初から、要件定義から画面仕様の作成までを設計チームが担い、開発チームがそれを実装するという分担で開発を進めてきました。2024年10月のリリースから約1年半が経った2026年4月、顧客への価値提供スピードをさらに高めるための部の方針として、 UI設計をフロントエンドが担う体制 へと移行しています。 実際に担ってみると、実装を担当していた頃には見えていなかった景色と、いくつもの壁にぶつかりました。この記事では、この体制に至った背景・進め方と、現時点で向き合っている課題をお伝えします。 1. 前提となる開発体制 2. なぜ踏み出す必要があったのか 設計フェーズに負荷が集中していた なぜフロントエンドだったのか プロトタイプを作るコストが下がった プロダクトのフェーズも変わってきた 3. まずは小さくUI設計を担う 立ち上げは小さく、定着は着実に Before → After 進め方 4. 担ってみて見えてきた、3つの課題 課題① 顧客・業務理解を深める 課題② UIパターンの引き出しを増やす 課題③ 設計意図を言語化する 5. 一歩踏み出した先に見えてきた、次の景色 おわりに 1. 前提となる開発体制 『楽楽請求』は、クラウド型請求書処理システム市場へ後発として参入したプロダクトです。初期フェーズでは、市場のニーズに迅速に応え、PMF（Product Market Fit）を達成することが最重要課題でした。初期メンバーによる徹底した現場視点と迅速な価値提供があったからこそ、現在の『楽楽請求』の成長につながっています。 当時の役割分担は次のとおりです。 製品企画チーム ：どの機能を作るかの企画を担当 設計チーム ：要件定義から概要設計まで。その一環として、FigmaでのUI設計までを担当 開発チーム（バックエンド・フロントエンド） ：詳細設計・実装・テストを担当 この明確な分担は、開発効率を高めるうえで大きく機能してきました。設計チームは要件と画面仕様の検討に、開発チームは実装品質にそれぞれ集中できる。短期間で多くの機能を届けられてきたのは、この体制があったからだと思っています。 私が参画した当時、『楽楽請求』では楽楽シリーズ共通のUIの統一がすでに完了していました。統一された画面をベースにできるため、Figmaの画面仕様は設計チームが作成し、必要に応じてデザイナーに依頼する形で運用されています。 これから紹介するのは、この分担を否定する話ではありません。 共通基盤が整っているからこそ、UI設計を誰が担うのが最も速いかを、組織として問い直した 話です。 2. なぜ踏み出す必要があったのか 設計フェーズに負荷が集中していた 体制上の制約がありました。当時の設計チームは少人数で、事業部の製品企画と連携しながら、要件定義から画面仕様の作成までを一手に担っていたことです。 企画・要件・UI設計が直列でつながっているため、どれか一つが詰まれば後続がすべて待つ構造になります。開発チームは実装の準備ができていても、画面仕様が出てくるまで着手できない。顧客に価値を届けるスピードを高めるうえで、ここが構造的な制約になっていました。 問題 ：要件定義からUI設計までが少人数の設計チームに集中し、設計フェーズが価値提供スピードの制約になっていた 課題 ：UI設計を分担し、設計チームが要件の検討に集中できる状態をつくる その課題解決の案が、フロントエンドの役割の引き直しでした。 なぜフロントエンドだったのか 理由は大きく2つあると理解しています。 ひとつは、 UIを実際に動く形にできること です。フロントエンドがUI設計からプロトタイプ作成までを一気通貫で担えば、設計と検証の間の受け渡しがなくなります。 もうひとつは、 実装して初めて見えることがある という点です。実装フェーズに入り、実際に動く画面を触る中で、次のような気づきを得ることがありました。 この操作フローだと、ユーザーが迷う場面がありそうだ この情報配置だと、目的の項目にたどり着くまでに時間がかかりそうだ この入力体験は、もう少し工夫の余地がありそうだ ただ、その時点では開発プロセスもすでに後半で、操作体験を大きく変更することは難しい状態でした。 ここで起きているのは、誰かの検討が足りなかった、という話ではありません。Figmaの画面仕様は、情報設計やレイアウト、コンポーネントの選定といった判断を固めるうえで欠かせないものです。ただ、操作の連続性や入力のテンポといった「実際に動かしてみないと分からない情報」を、設計フェーズの時点で確かめる手段がありませんでした。 だとすれば、実装まで担うフロントエンドが設計段階から関わり、動く状態で確かめてしまえばいい。この2つが重なった結果としての体制変更だったと捉えています。 プロトタイプを作るコストが下がった もうひとつの後押しが、開発組織全体で進んでいる「AIを活用した開発スタイル」への転換です。 AIを活用することで、アイデアや仕様を素早く動くプロトタイプとして形にできるようになりました。これまでは「作ってから検証する」ことのコストが高く、現実的な選択肢になりにくかった。そのコストが下がったことで、設計フェーズで動かして確かめる進め方が、例外ではなく標準の選択肢になったと考えています。 プロダクトのフェーズも変わってきた 機能拡張は今も続いており、強化すべき領域は残っています。 一方で、ユーザーの声を聞く中で見えてきたのは、画面の見やすさ以上に、 日々大量の業務をどれだけストレスなく処理できるか という操作感そのものへの期待でした。 そのため、次のような観点で体験の質を磨き込むことの優先度が、以前より上がってきていると感じています。 直感性 ：初めて触るユーザーでも迷わず操作できること 効率性 ：無駄な画面遷移やステップを削ぎ落とし、大量の処理をスピーディーに行えること 信頼性 ：誤操作や確認漏れを防ぎ、日々の業務で安心して使えること 3. まずは小さくUI設計を担う 立ち上げは小さく、定着は着実に 方針が決まったとはいえ、これまで実装を中心に担ってきた私たちが、いきなり全機能・全工程を引き受けるのは現実的ではありません。 そこで ラクスリーダーシッププリンシプル（RLP） の一つである「小さく試して大きく育てる」を意識し、今後リリース予定の新機能から着手することにしました。現時点で実践したのは2案件です。 小さく始めたのはあくまで立ち上げ方の話であり、単発の試行として終わらせるつもりはありません。この2案件で得た手応えと課題をもとに、今後の新機能開発の標準にしていくことを目指しています。 Before → After 体制のBefore→After 進め方 概要設計で整理された機能要件をもとに、フロントエンドがUIを設計し、実際のコードでプロトタイプまで作り込みます。画面遷移や入力操作を本物同様に試せる状態にするのがポイントです。 設計チームが概要設計（機能要件の整理） フロントエンドがUIを設計し、プロトタイプを作成 フロントエンドチーム内でレビュー 設計チームによるレビュー・仕様の確定 UIのブラッシュアップ 本実装 UI設計そのものはフロントエンドが担いますが、 仕様の確定は設計チームとの合意を経て行います 。要件の背景や事業判断を持っているのは設計チームであり、そこと接続されていないUIは成立しないためです。役割を引き取ったというより、UI設計の検討をフロントエンド側に前倒しし、二者で詰める形に変えた、という表現が近いと思います。 実際、プロトタイプを持ち込むことで、言葉や画面仕様だけではイメージを揃えにくかった操作感について、設計チームと早い段階で具体的な議論ができるようになりました。 4. 担ってみて見えてきた、3つの課題 始めて数か月が経ちました。設計フェーズの領域に踏み込んだからこそ、向き合うことになった課題が3つあります。 課題① 顧客・業務理解を深める 最も大きな壁が、ドメイン知識と業務フローの理解でした。 実装に必要な理解と、UIを設計するために必要な理解には、思っていた以上に差がありました。「ユーザーはどういう業務の文脈で、どのタイミングでその設定を変更したくなるのか」「前後の作業とどう繋がっているのか」。ここを押さえていないと、業務に馴染むUIにはなりません。 → 営業商談の録画視聴、設計チームとのディスカッション、経理業務の専門書などを通じて、インプットを継続しています。 課題② UIパターンの引き出しを増やす 顧客の業務が理解できても、それを直感的なUIへ落とし込むには別のスキルが必要でした。 情報量の多い設定画面において、「ポップアップで出すべきか、インラインで表示すべきか」「どのように視覚的なガイドを出せば迷わないか」。こうした選定を、経験則や感覚だけで判断してしまう場面がありました。 → UI/UXデザインや各種UIパターンを学び、既存画面に積み上げられてきた判断の意図を読み解きながら、選定の引き出しを増やしています。 課題③ 設計意図を言語化する 「なぜこのUIにしたのか」を言語化し、関係者に説明する力も新たなハードルでした。 プロトタイプを持ち込んでも、「使いやすそうだから」では議論になりません。「この操作フローならユーザーの思考を妨げない」「実装コストとのバランスが良い」といった理由を、ビジネス視点も含めて説明し、合意形成を図る必要があります。 → プロトタイプを軸にした早期のすり合わせを重ね、意図を説明する力を磨いています。 3つ並べて改めて思うのは、これらはいずれも、 少人数の設計チームが日常的に引き受けてきたことの一端 だということです。自分で担ってみて初めて、その難しさを実感しました。 5. 一歩踏み出した先に見えてきた、次の景色 運用面では、詰めるべき論点も残っています。プロトタイプと本実装の境界線をどこに引くか、UI仕様のドキュメントをどう管理するか。この進め方をチームの標準として定着させるうえで、避けて通れないテーマです。 そうした中で、直近では私自身が設計メンバーとして設計チームに加わることになりました。より事業や顧客に近い場所で、課題解決や設計判断に携わっていくことになります。 実装に閉じず、顧客視点でプロダクトづくりを主導できるエンジニアになる。そこに向けた、はじめの一歩だと思っています。 おわりに 今回紹介した取り組みは、正直に言えば、まだ「成功事例」と呼べる段階ではありません。課題のほうが山積みです。それでも、「より良いプロダクトを作りたい」という思いから踏み出した以上、ここから引き返すつもりはありません。 この記事が、「もっとプロダクトの意思決定に関わりたい」と考えているフロントエンドエンジニアの方にとって、何かのヒントになれば幸いです。 設計チームの一員として見えてくる景色や、そこでの気づき・失敗についても、機会を見てまたお伝えできればと思います。

目次 はじめに 前提：私たちのチームの開発の進め方 Working Backwardsに着目した理由 「機能リリース概要」という形にアレンジした 課題は、文章を書く手間 AIで上流工程を効率化する まとめ はじめに 楽楽勤怠の給与計算オプションのプロダクトマネジメント / プロダクトオーナーをしている @k0First です。 機能の仕様を決める際、事業部との認識合わせに何度もやり取りが発生したり、開発に渡した後で仕様の意図を確認されたりすることがあります。原因を振り返ると、多くの場合、最初に作成するドキュメントで伝えるべき情報が伝えきれていないことに行き着きます。 この記事では、Amazonの「Working Backwards」という考え方を参考に、自分たちの開発体制に合わせてドキュメントの作り方を見直し、AIを使って作成を効率化した取り組みを紹介します。 前提：私たちのチームの開発の進め方 会社によって開発の進め方は異なるため、先に前提を整理しておきます。 給与計算オプションでは、機能のロードマップを事前に企画課と協議して決めています。そのうえで、各機能の仕様についてはプロダクトオーナーがドキュメントを作成し、事業部と協議しながら確定させていく流れです。 デザイナーはこのドキュメントをもとにデザインを作成し、バックエンド・フロントエンドのエンジニアは、できあがったデザインとドキュメントをもとに開発を進めます。 つまり、プロダクトオーナーが最初に作成するドキュメントが、事業部との認識合わせの土台になると同時に、デザインや開発の起点にもなります。このドキュメントの内容が不十分だと、その影響は後工程にそのまま伝わることになります。 Working Backwardsに着目した理由 Working Backwardsは、Amazonが新しいサービスや機能を企画する際に用いている手法です。開発に着手する前に、その機能が完成した後を想定した顧客向けのプレスリリースをまず書き、あわせてQ&A（FAQ）をまとめます。この一式はPRFAQ（Press Release and Frequently Asked Questions）と呼ばれています。 開発企画は、放っておくと「今の仕組みや技術でできること」を起点に積み上げがちです。その積み上げ方だと、できあがってから「これは誰の、どんな課題を解決しているのか」が曖昧なまま進んでしまうことが起こり得ます。Working Backwardsは、完成後の顧客向け発表文を先に書かせることで、企画の起点を強制的に顧客の課題や体験に戻す仕組みだと理解しています。プレスリリースという体裁上、専門用語や社内事情に頼った説明ができず、平易な言葉で価値を言い切る必要がある点も、考えを整理するうえで機能しているようです。 この考え方は、私たちが抱えていた課題とも重なる部分がありました。事業部との認識合わせに時間がかかるのも、開発から仕様確認が入るのも、突き詰めると「その機能が何を解決するのか」「仕様の意図は何か」が、最初のドキュメントの時点で言い切れていないことが原因だったためです。 ただし、そのままの形式を持ち込むことはできませんでした。Amazonのプレスリリースは顧客向けの発表文であるのに対し、私たちが作成するドキュメントの読者は事業部や開発メンバーだからです。 そこで、「価値と仕様を先に言語化する」という発想だけを取り入れ、形式は自分たちの読者に合わせて作り直すことにしました。 ※Working Backwardsについては、こちらを参考にしてください。 🔗 参考リンク アマゾンの最強の働き方――Working Backwards （コリン・ブライアー、ビル・カー著） プレスリリース先行で企画を作るAmazon流のやり方【企画の道具箱 #7】 「機能リリース概要」という形にアレンジした 作成したのは、「機能リリース概要」というドキュメントです。 顧客向けのプレスリリースではなく、事業部向けのプレスリリースに近い形式にしました。前半には「どのような機能を出すのか」「その機能が顧客のどのような課題を解決するのか」を記載し、後半には事業部・開発メンバー向けに詳細な仕様を記載します。 さらに、このドキュメントを読んだ事業部や開発メンバーから想定される質問を、Q&A形式でまとめました。1機能につき1ドキュメントとして、機能概要とQ&Aをセットで扱う運用にしています。 この形式にしたことで、事業部との協議は、ゼロから説明するものではなく、すでに言語化された内容をもとに認識をすり合わせるものに変わりました。 課題は、文章を書く手間 一方で、この機能リリース概要には作成コストの課題がありました。 1機能1ドキュメントで、機能概要・詳細仕様・Q&Aまでを揃えるとなると、書く文章量は少なくありません。事業部や開発メンバーに伝わる内容にするには、言葉の選び方にも配慮が必要です。 その結果、仕様の検討そのものよりも、それを文章に落とし込む作業に時間がかかる状態になっていました。上流工程の進め方を変えても、この部分がボトルネックになっては意味がありません。 AIで上流工程を効率化する この課題に対して、次のような流れを取り入れました。 機能リリース概要のテンプレートを、あらかじめ作成しておく テンプレートに沿って、ドラフトを作成する あらかじめ定義したブラッシュアップの観点（Skill）をもとに、AIでブラッシュアップする 完成した機能リリース概要をもとに、Q&AをAIで自動作成する ポイントは、最初のドラフトは自分で書くことです。給与計算オプションは法令や計算ロジックが絡み、仕様の正確性が求められる領域のため、何を書くべきかという判断はプロダクトオーナーが担い、AIには文章を伝わりやすく整える役割を任せています。 ドラフトの作り方自体は、特別なことはしていません。テンプレートの各項目を、まず箇条書きでとりあえず埋めていきます。伝えたい内容がすでに固まっている項目については、箇条書きを飛ばして最初から文章で書いてしまうこともあります。AIに読み込ませることを意識した書き方の工夫は、特にしていません。箇条書きでも文章でも、その時点で自分が把握している情報をテンプレートの構造に沿って書き出しておく、というだけです。 ただし、入力値や出力値があらかじめ決まっている項目については、箇条書きの段階で書き切るようにしています。たとえば給与業務であれば、給与振込FBデータのように対外的に出力する項目の内容は決まっているので、ドラフトの段階で該当する値をすべて列挙しておきます。ここを曖昧にしたまま先に進めると、後工程で認識のズレが起きやすい部分だからです。構造さえテンプレートに沿っていれば、その後のブラッシュアップはSkill側の指示でカバーできるようになっています。 社内には、仕様が固まりきらない案件で、 最初からAIに書かせて書き直させるという進め方をしたチームの事例 もあります。書き直しが前提の、失敗コストが低い領域だからこそ成立する進め方だと考えています。給与計算オプションのように正確性が優先される領域では、人が骨格を作り、AIには磨きを任せる方が適していると判断しました。 ブラッシュアップについては、都度チャットで指示を出すのではなく、どのような観点で直すかをあらかじめSkillとして定義しています。「事業部が読んでもわかる粒度になっているか」「前半と後半で情報の重複や矛盾がないか」といった観点をSkill側に持たせておき、実際の作業ではGoogleドキュメントのリンクを貼り付けるだけで、その観点に沿ったブラッシュアップが行われる形にしています。毎回同じ指示を書き直す手間がなくなり、ブラッシュアップの精度も安定するようになりました。 機能リリース概要が完成した後は、その内容をもとにQ&Aの作成もAIに任せます。ドキュメントを読み込ませたうえで、事業部や開発メンバーが疑問に思いそうな点を洗い出してもらう形です。自分だけで質問を想定すると視点が偏りやすいため、この工程は特に効果を感じています。 この仕組みは、完成後の修正でも活きています。開発中に仕様変更が発生した場合、該当箇所を書き換えたうえで同じブラッシュアップのSkillを呼び出せば、テンプレートの構造や表現ルールに沿った形にすぐ整え直せます。ドキュメントの体裁を保つための調整を都度自分でやり直す必要がなく、仕様変更への対応スピードにもつながっています。 参考までに、ブラッシュアップのSkillに定義している指示の一部を抜粋します。実際にはもっと長い指示書ですが、骨子は次のようなものです。 あなたは、勤怠管理・給与計算システムの「機能リリース概要」をブラッシュアップする編集アシスタントです。 読者は、事業部（営業・カスタマーサクセス・サポート・導入支援）と開発部（バックエンド・フロントエンド・デザイナー・QA・保守運用）を想定します。 # 最重要ルール - 「機能要件（Must / Better）」は、必ず機能単位でテンプレート構造（概要・入力・出力・処理・業務ルール・エラー・備考）を維持する - テンプレート構造を独自変更したり、機能をまとめたりしない # 基本方針 - 社内仕様書として自然な敬体で記載する - 冗長な説明は避ける - 元資料の内容を尊重する - 指定範囲外を大きく変更しない - 不明点は断定しない - 読みやすさよりテンプレート準拠を優先する # 出力形式 - Markdownで出力し、Googleドキュメントに貼りやすい形にする - 「本文タブ用」「Q&Aタブ用」の順にコードブロックで出力する 読者の想定、テンプレート構造の維持、出力形式まで指示に落とし込んでおくことで、Googleドキュメントのリンクを貼るだけでも、毎回一定の品質でブラッシュアップされるようにしています。 この進め方に変えてから、ドキュメント作成にかかる時間は短くなりました。事業部との協議でも、機能の概要説明に使っていた時間を、認識のすり合わせそのものに使えるようになっています。 一方で、AIに任せられない部分もあります。何を書くべきか、どこまでを今回のスコープとするかという判断は、ドメイン知識をもとに人が行う必要があります。AIに任せるのは、内容を伝わる形に整える工程と、そこから疑問点を洗い出す工程で、判断そのものは自分たちで行う。この役割分担が、現時点では最も機能しています。 まとめ Working Backwardsをそのまま自分たちの開発に当てはめることは難しいと感じました。読者もドメインも異なるためです。 一方で、「価値と仕様を、開発に着手する前に言語化しておく」という考え方自体には、取り入れる価値がありました。形式は自分たちの読者に合わせて作り直し、「機能リリース概要」というドキュメントに落とし込みました。 そのドキュメント作成にかかる手間は、AIを活用することで軽減できました。ここでも、AIに何を任せ、何を自分たちで行うかの線引きは、扱っているドメインの特性に合わせて考える必要がありました。 Working Backwardsも、AIの活用も、そのまま取り入れるのではなく、自分たちの体制やドメインに合わせて調整していく。今回の取り組みを通じて、そのことを改めて確認できました。

はじめに LLMのAPIを叩いて何かを作ること自体は、ずいぶん手軽になりました。プロンプトを書いて実行すれば、それらしい出力が返ってきます。 ただ、「手元で動くもの」と「お客様に提供できる機能」の間には、かなりの距離があります。手元では良い感じの出力が出ていたのに、いざ幅広いデータで試すと精度が安定しない。精度は出たけれど処理が遅すぎる、あるいはコストが見合わない。本番のコードに載せ替えたら、なぜか検証時と結果が変わってしまう。このあたりで足踏みした経験のある方も多いのではないでしょうか。 そこで本記事では、LLMを使った機能開発を進める際の「何から手をつけて、どういう順番で進めるべきか」という進め方について、4つのステップに分けて整理してみます。 特定のフレームワークやサービスの使い方の話ではなく、AI機能を開発する際の「型」の話です。これから機能開発に着手する方や、一度作ってみたものの本番化で足踏みしている方の参考になれば幸いです。 はじめに 開発フローの全体像 1. 見極めと評価準備 AIで解けるタスクかの見極め 精度評価方法の構築 2. 評価と改善 現状把握と目標ラインの設定 評価結果の分析と改善策の実施 目標ラインに達するまで反復する ── そして深追いしない 3. FIXと本番実装 モデル・プロンプト・処理フローのFIX 本番実装用コードの仮作成と再検証 本番実装の完成 4. リリース後の運用と継続的改善 実データで弱点を見つけ、ベンチマークを育てる 改善はリリース前と同じ手順で適用する モデル更新とコストに追従する おわりに 開発フローの全体像 まずは全体像です。次の4ステップで進めるのが良いと考えています。 見極めと評価準備 ：AIで解けるタスクかを確かめ、精度を評価する仕組みを作る 評価と改善 ：目標ラインを設定し、達するまで評価と改善を繰り返す FIXと本番実装 ：構成を凍結し、本番用コードに載せ替えて再検証する リリース後の運用と継続的改善 ：実データで弱点を見つけ、ステップ2のサイクルに戻る 1〜3はリリースまでの一本道ですが、4だけは性質が違います。リリース後に実データを使ってステップ2の評価と改善に戻ってくる、大きなループになっています。 以降で、それぞれのステップを順に見ていきます。 1. 見極めと評価準備 AIで解けるタスクかの見極め 最初にやるべきは、解決したいタスクがそもそもAIで解けるものなのかを確認することです。前提として、そのタスクが「人間なら解決可能で、人間が解決手順を整理して説明できること」を満たしているかを考えます。人間が説明できない仕事は、AIにも任せられません。 そのうえで、利用可能な中で最も性能の良いモデルで、タスクが解決できるかを試します（動かすための最低限のコードとプロンプトは用意しておきます）。 最高性能のモデルでも解けない場合は、タスクそのものを見直します。AIに任せられそうな作業だけを切り出す、作業を細かく単純なものに分割してそれぞれをAIに解かせる、といったアプローチが有効です 解けた場合は、性能の劣るモデルでも解けるかを試して使えるモデル性能の下限を探り、予算やパフォーマンスの要求仕様に合うモデルの目星をつけておきます ※この時点では、少量のケースで「だいたい解けそうか」を人手で確認する程度で十分です。プロンプトの作り込みもまだしません。幅広いケースで解けるかどうかは、後のステップで検証します。 精度評価方法の構築 AIで解けそうだと確認できたら、より多くのデータで定量的に性能を評価する方法を用意します。必要なのは次の3つです。 ベンチマークデータ ：実際に扱うことになるデータのパターンを、できるだけ網羅するように幅広く選びます 正解の回答例 ：そのデータが入力されたとき、どんな出力であれば正解なのかの例を用意します スコア算出方法 ：AIの出力と回答例を突き合わせてスコアを出す仕組みです。データ読取のように正解が明確に決まるタスクなら正解率／適合率／再現率、文章生成のように出力が正解と一致するとは限らないタスクなら、ベクトル化とコサイン類似度や、LLMによる一致度評価が候補になります。「XXXが書かれていること」のような基準を予め設定し、出力が基準を満たすかをLLMに判定させる方法もあり、この場合は正解例がなくても評価できます 評価の仕組みが整ったら実際にスコアを算出してみて、 そのスコアがAIの出力に対する人間の印象と一致するか を確認します。特に文章生成のようなクリエイティブ要素のあるタスクでは乖離が起こりやすく、例えば人間が「80点くらいかな」と感じる出力に評価スコアが50点しかつかないなら、評価基準が厳しすぎると考えて基準を緩めることを検討します。 2. 評価と改善 現状把握と目標ラインの設定 評価方法ができたら、まず最低限の実装の状態で評価を行い、現状を把握します。このとき精度だけでなく、処理速度、エラーの発生率、コストも併せて把握しておきます。 そのうえで、目標ラインを設定します。精度については、現状の実装の精度やタスクの難易度、モデルの性能を総合的にみた現実的な水準で、かつプロダクトとして必要とされる水準を満たすラインを引きます。処理速度やコストにも目標を設けます。精度だけを追求しても、処理速度が遅すぎる・コストが高すぎるのでは意味がありません。 ※ LLMの出力は実行のたびに変化します（ temperature=0 や top_p=0.1 のように確定的になる設定にしても変動します）。同じ条件で複数回評価を実行して平均を取ると、信頼できる結果になりやすいと思います。 評価結果の分析と改善策の実施 精度が目標に届かない場合は、原因の分析から入ります。精度が低かったデータについて、正解例や正解基準と照らし合わせて、出力のどこがどのようにできていないのかを人手で確認します。より高性能なモデルなら良い品質の出力ができるのであれば、モデル性能にも一因があると言えます。複数の工程からなるタスクを1つのプロンプトで実行している場合は、プロンプトを分割して実行し、どの工程に原因があるかを切り分けます。 原因が見えてきたら、改善策を実施します。 できていなかった部分の是正案をプロンプトに盛り込み、同じ間違いを繰り返さないようにする より高性能なモデルに切り替える プロンプトを工程ごとに分割し、AIが行う1つ1つのタスクを単純化する ※ 高性能モデルへの変更やプロンプトの分割実行は、コスト増の原因になります。逆に「1つのモデルで精度が出たからOK」でもなく、より低コストのモデルで同等の性能が出せないかも確認し、コストと精度のトレードオフを常に意識することをおすすめします。 目標ラインに達するまで反復する ── そして深追いしない 改善策を実施したら再度評価を行い、効果が出ているかを確認します。効果が不十分なら分析からやり直し、目標ラインに達するまでこの評価と改善のサイクルを繰り返します。 ここで意識したいのは、 目標ラインに達したら、それ以上数字を深追いしない ことです。あらゆる入力に対して完璧な出力を返すようにモデルやプロンプトをチューニングするのは、そもそも困難です。リリース前に数字を追い込むよりも、そこそこの精度のあるものを早期にリリースし、ユーザーからのリアルなフィードバックに基づいて改善したほうが、得られる価値は大きいと思います。 3. FIXと本番実装 モデル・プロンプト・処理フローのFIX 目標に達したら、その結果を出した構成をそのまま凍結します。後の工程で精度が落ちたときに、原因が実装側にあるのか構成変更にあるのかを切り分けられるようにするためです。 固定する対象は、モデル名（できればエイリアスではなく、日付等が記載された特定のスナップショットを指定します）、推論パラメータ（temperature、top_p、max_tokens、seed など）、プロンプト全文、入出力のスキーマ、前後処理のロジックです。 併せて、FIX時点の評価スコア（以降のすべての比較の基準値になります）、その構成に至った理由と試したが不採用にした案、ベンチマークデータと評価スクリプト一式も残しておきます。評価一式は、機能の追加・修正の際に精度劣化していないかを確認する回帰テストとして、そのまま使い回します。 ※ プロンプトはコードに直書きせず、バージョン管理できる形で外出ししておくと、後の改善サイクルが回しやすくなります。 本番実装用コードの仮作成と再検証 検証用コードと本番用コードでは、求められるものが違います。検証段階では1回動けばよいコードでも、本番では失敗すること前提の作りが必要になります。具体的には、エラーハンドリングとリトライ（タイムアウトやレート制限に対する指数バックオフ）、出力フォーマットのバリデーションと崩れていた場合の再実行、規定回数失敗したときの縮退動作、入力・出力・トークン数・処理時間のログ記録、レート制限と折り合いをつけた並列化、認証情報の管理とコスト集計の仕組みなどです。 まずは作り込みすぎず、通しで動くものを仮に作ります。次にその仮の実装をステップ1で用意した評価手法で評価し、 検証時の結果が再現するか を確認します。見る観点は、精度がFIX時点のスコアと同水準か、処理速度（平均だけでなく遅い側も見ます）、並列実行時のレート制限への到達具合とエラー率、1件あたりと想定件数での月次コスト、異常系の入力（空、極端に長い、想定外の文字種）で落ちずに処理できるか、です。 ※ 検証時と本番では、プロンプトへのデータの入り方（エスケープ、改行の扱い、文字数上限による切り詰め）が変わりやすく、これが精度劣化の典型的な原因になります。精度が再現しない場合は、モデルやプロンプトを疑う前に、まず実装の差分を潰します。 本番実装の完成 再検証で見つかった問題を修正し、運用に耐える状態に仕上げます。このとき、機能として動くことに加えて、 リリース後に改善サイクルを回せる状態になっていること が完成条件になります。 監視とアラート ：エラー率、処理時間、コストの急増を検知できるようにする 入出力ログの蓄積 ：どの入力で品質が悪かったかを後から追跡し、ベンチマークデータに追加できるようにする ユーザーからのフィードバック導線 ：出力に対する評価や修正内容を回収できるようにする 安全面の対処 ：個人情報のマスキング、プロンプトインジェクションへの対策、出力をそのまま外部に出す場合のフィルタ 段階的リリースの仕組みと運用手順の文書化 ：一部ユーザーへの先行公開や問題時に切り戻せる導線、障害時の対応やモデル更新時の再評価手順 ステップ2の最後に書いたとおり、リリース前に完璧を目指すよりも、そこそこの精度で早く出してユーザーの反応をもとに改善するほうが価値があります。そのための「早く出せる仕組み」と「改善を回せる仕組み」を、この工程で用意しておくイメージです。 4. リリース後の運用と継続的改善 リリースは検証の終わりではなく、実データでの検証の始まりです。 開発中のベンチマークデータは、あくまで自分たちが想定した入力パターンの集合でしかありません。実際のユーザーが入れてくるデータは想定を外れることが多く、リリース後に初めて分かる弱点があります。ステップ3で用意したログとフィードバック導線を使って、ステップ2の評価と改善のサイクルを本番データで回し続けます。 実データで弱点を見つけ、ベンチマークを育てる まず、精度が低かったケース（ユーザーがやり直した、大幅に手直しした、フィードバックで低評価がついた入力）や、開発時のベンチマークに無かった想定外の入力パターンを、実データから拾い上げます。「精度が悪い」という報告だけでは改善できません。 どの入力に対して、どんな出力が返り、期待されていた出力は何だったのか 。この3点が揃う形で、ログとフィードバックを回収できるようにしておきます。 見つかった失敗ケースはベンチマークデータに追加し、評価セットを育てていきます。追加直後はスコアが下がりますが、これは評価が実態に近づいたということです。再評価の際は追加分だけでなく既存分も必ず一緒に評価します。特定ケースの対策で他が壊れる（デグレする）ことは頻繁に起こります。 ※ ベンチマークデータが実データを反映して充実していくほど、評価の信頼性が上がり、改善のスピードも上がります。ここへの投資が、長期的には一番効いてくると感じています。 改善はリリース前と同じ手順で適用する プロンプトを修正したら、リリース前と同じ回帰テストを通してから反映します。変更は一度にまとめず効果を切り分けられる単位で入れ、可能なら一部ユーザーで先に試してから全体に広げ、変更内容と前後のスコアを記録に残します。プロンプトの修正は1行の変更でも挙動が大きく変わるため、コード変更と同じ扱いで、レビューとテストを経て反映する運用にしておくのがよいと思います。 モデル更新とコストに追従する LLMは提供側の都合でモデルが更新・提供終了されるため、追従は避けられないものとして手順化しておきます。新モデルが出たら、既存のベンチマークで旧モデルと精度・速度・コストを比較評価します。上位モデルだけでなく、より低コストのモデルで同等の精度が出ないかも都度確認します。モデルの価格性能比は継続的に改善されているため、リリース時点の最適解が半年後も最適とは限りません。使用中モデルの提供終了期限を把握し、期限前に移行検証の時間を確保しておくことも必要です。 ※ モデルを差し替えると、旧モデル向けにチューニングしたプロンプトが最適でなくなることがあります。モデル変更時は、プロンプトの見直しもセットで考えます。 コストについても、実際の利用量に基づく月次コストを定点観測し、想定より高い場合はプロンプトの短縮、キャッシュの活用、モデルのダウングレード、処理の分割方法の見直しなどを検討します。 おわりに 4つのステップを並べてきましたが、通してみると、特別なことは何もしていません。「目標を決め、評価し、改善する」という当たり前のサイクルを、AI機能開発の文脈に置き直しただけとも言えます。 しかしLLMを使った開発では、この当たり前が思いのほか難しいこともあります。 出力が実行のたびに変わるため「(一時的な)良くなった気がする」で判断しがちですし、手元では動いてしまうぶん、評価の仕組みを作る前に作り込みを始めてしまいがちです。だからこそ、 作り込む前に評価する仕組みを用意しておくこと が、堅実に開発を進めるために重要になってきます。 もう1つの難しさは、やめ時が分かりにくいことです。あらゆる入力に対して完璧な出力を返すようにチューニングすることは、そもそもできません。一方で、リリースすればユーザーのフィードバックという社内の検証では得られない貴重なデータを得られます。完璧を目指して社内で磨き続けるより、 目標に達したら深追いせず早く出し 、ユーザーのフィードバックに応えていくほうが、結果的に良いものになるはずです。 これから機能開発に着手する方や、本番化の手前で足踏みしている方にとって、進め方を考えるきっかけになれば幸いです。

【目次】 AIが入っていない場所を探したら、上流工程が残った なぜ「概要設計書」を選んだのか 「書き直させる」前提で、最初からAIに書かせた つまずいたのは、スライドのデザインとUIのデザインの混在 ツール選定に、20分以上かけない 体感で2〜4倍。ただし数値化はこれから 生まれたバッファは、顧客の声を拾う時間へ まとめ こんにちは、ラクス技術広報です。 開発本部では、各部署でのAI活用の取り組みを技術広報がインタビューし、記事としてお届けしています。今回お話を伺ったのは、経費・請求・販売管理などのクラウドサービスを展開するラクスで、販売管理クラウドサービス「楽楽販売」の開発を担う 楽楽販売開発1課の前田啓佑さん です。 前田さんが取り組んでいたのは、コーディングでもテストでもありません。 「概要設計書をAIに書かせる」 ——つまり、開発の上流工程そのものでした。 「AIでコーディングを行い、テストを行うのは当たり前になりつつある。じゃあ今、AIの導入が遅れている場所はどこか。そう考えていくと、上流工程が残るんです」 この記事はこのような方におすすめです。 コーディングやテストのAI活用は進んだが、その先の伸びしろが見えなくなっている方 仕様が固まりきらない案件で、設計ドキュメントの書き直しに疲弊している方 AIツールの選定・比較検討に時間をかけすぎていると感じている方 速くすること自体が目的ではありません。空いた時間を何に使うのか？ぜひ考えるきっかけになると幸いです。 AIが入っていない場所を探したら、上流工程が残った 前田さんが所属する楽楽販売の開発チームでも、コーディングやテストコード生成でのAI活用はすでに日常の一部になっています。 課題として浮かび上がったのは、 開発プロセス全体で見たときのボトルネックの位置 でした。 「上流工程が遅延すると、結局、開発タスクが下に降りてこないんですよ。下流だけをどれだけ速くしても、そこは詰まったままになる。ボトルネックは上流工程にあると感じました」 コーディングが2倍速くなっても、その前段の設計に時間がかかっていれば、リードタイム全体はほとんど変わりません。AIが入っていない場所こそ、一番効きやすい場所だった、ということです。 ここが今回の取り組みの出発点になりました。 なぜ「概要設計書」を選んだのか 上流工程といっても範囲は広い。その中で前田さんが最初の対象に選んだのが、概要設計書でした。楽楽販売の概要設計書には、少し特殊な事情があります。 「楽楽販売の概要設計書は、事業部向けの説明資料も兼ねているんです。なので、普段はGoogleスライドで作成しています」 読み手が開発者だけではないため、ドキュメントには内容の正しさに加えて「説明資料としての体裁」が求められます。テキストベースの設計書に比べて、作成にも修正にも手間がかかりやすい構造です。 そして、今回対象にした案件は、 顧客の声から生まれた案件 でした。 顧客起点で始まった案件には、ひとつの特徴があります。解決すべき課題ははっきりしている一方で、それを どういう外部仕様で実現するかは、始まった時点では固まっていない ということです。 「具体的な外部仕様はハッキリとはしておらず、概要設計を何度も書き直すことになるのは明白でした」 書き直しは「起きるかもしれない」ではなく「明白だった」。この見通しが、次の判断につながります。 「書き直させる」前提で、最初からAIに書かせた 普通の順序であれば、まず人間が叩き台を作り、AIには補助的に手伝ってもらう、という発想になりそうなところです。前田さんは、その逆でした。 「最初からAIを使って書き、AIを使って書き直させる。そういう固い意思で概要設計を作り始めました」 使ったのは、Anthropicが2026年4月に公開した「 Claude Design 」です。テキストでの指示や対話を通じて、スライド資料やプロトタイプ、LPなどを作成できるツールで、執筆時点ではリサーチプレビューとして提供されています。前田さんはこれを使って、設計書のスライドそのものを生成しました。 前田さんの言葉で印象的だったのは、 「思いの外、精度が高いものが作れることに驚いた」 という点です。当初から成功を確信していたわけではなく、書き直し前提だからこそ試せた、という順序でした。 さらに効果が大きかったのは、修正フェーズだったといいます。 「『こういう修正をお願い』と言うと、全部のページに目を通して、修正すべき箇所を洗い出して修正してくれるんです。漏れなくやってくれる」 これは、スライド形式の設計書につきまとう典型的な問題に効いています。ページ数が増えるほど、一箇所の仕様変更が他ページに波及していることを見落としやすくなる。 「人間がやると、矛盾した記載が残ったりします。この辺はAIの方が優秀でした」 「速く書ける」だけでなく、 「書き直しても整合性が壊れない」 こと。書き直しが前提の案件においては、こちらの価値のほうが大きかったと言えそうです。 つまずいたのは、スライドのデザインとUIのデザインの混在 もちろん、すべてがうまくいったわけではありません。前田さんが最も苦労したポイントは、 スライドのデザインと、画面UIのデザインが、AIの中で混ざってしまう ということでした。 概要設計書では、新機能の画面イメージを説明する必要があります。つまり1枚のスライドの中に、 資料としてのレイアウト（見出し、余白、図解の配置） 説明対象であるプロダクトのUIデザイン という、性質の異なる2種類のデザイン情報が同居することになります。AIから見ると、この2つは区別しづらい。 結果として、UIの説明図がスライドの装飾に引きずられたり、その逆が起きたりします。 前田さんが出した結論は、 分業させる ことでした。 「UIのデザイン案は、別で作らせた方が早くて綺麗なものができそうです」 ただし、前田さんはこれを「常に分けるべき」とは言いません。 「ただ、まだまだ修正が入るフェーズなら、叩き台としてこれで良い、と妥協するのも必要だと思います。効率を考えて使い分けるべきですね」 ここは、AI活用の実務でかなり効く判断だと感じました。 「AIの出力品質をどこまで上げるか」ではなく「今このフェーズで、どこまで上げる必要があるか」から逆算する。 仕様が動く前提の段階で見た目を磨き込んでも、その労力の多くは次の書き直しで消えてしまいます。 ツール選定に、20分以上かけない 「なぜこの方法を選んだのか。他の選択肢と比較検討はしましたか？」 この質問への答えが、今回のインタビューで印象に残った部分でした。 「正直、こだわりはなかったです」 比較検討をしなかった、という話ではありません。前田さんが問題視していたのは、 比較検討そのものにかかる時間 でした。 「今はどんどん新しいツールが出るし、料金プランの変更も1ヶ月単位で発生し続けています。悩んでいる時間が、開発速度を鈍化させる」 半年かけて選定した最適解が、選び終わった頃には最適ではなくなっている。変化の速度が意思決定の速度を上回っている領域では、慎重な比較検討がそのままコストになる、という指摘です。 「闇雲にやれば良いとは言いません。ただ、例えば20分調べて良さそうなツールを見繕って、その中から自分が良いと思うものを選んで、実際にトライアンドエラーを始める。その方が効率的じゃないかと思います。今のラクスに求められているスピードは、そういうことだと思っています」 ラクスの行動指針には「小さく試して大きく育てる」という項目がありますが、この判断はまさにそれを地でいくものだと感じました。 机上で最適解を探すより、手を動かして得られる情報のほうが速くて確かだ という割り切りです。 なお、これは「検討を放棄してよい」という話ではないはずです。今回のケースでは、書き直し前提のドキュメント作成という 失敗コストの低い領域 から始めているという前提があります。試す場所の選び方とセットで受け取るのが実態に近そうです。 体感で2〜4倍。ただし数値化はこれから では、実際どれくらい速くなったのか。 「まだ概要設計は完了していませんが、速度も品質も段違いであることは明らかです。体感ですが、2倍〜4倍は早く仕上がります。数値化できていなくて申し訳ないですが……」 ここは、記事としてもそのまま正直に書いておきたい部分です。 現時点で計測された数値ではなく、進行中の案件における作業者本人の体感値 です。今後、案件が完了した段階で改めて振り返る余地が残っています。 一方で、前田さんが強調していたのは倍率そのものよりも、その手前にある事実でした。 「これまでAIが入っていなかった場所にAIが導入されるというのは、測れないくらいに改善効果が大きいと再確認しました」 すでにAIが入っているところをさらに磨いても、上がり幅はだんだん小さくなっていきます。一方で、ゼロだったところに入れたときの差は桁が違います。 伸びしろは、まだAIを使っていない場所にある。 これが今回の取り組みから得られた、最も再現性の高い学びだと感じました。 生まれたバッファは、顧客の声を拾う時間へ 最後に、他チームにも共有したいことを尋ねました。 「AIの進化で開発の現場が劇的に変化している昨今ですが、我々が求められている開発速度はこんなもんじゃない、と思っています。固定概念に囚われずに、もっと遥か高みを目指してほしいです」 そのために日々持ち続けたい問いとして、前田さんは2つを挙げてくれました。 手でやっている作業は、AIで代えられないか？ そもそも、やる意味がある作業か？ 後者が併記されているのが重要なところだと思います。AIで速くすることと、そもそもやめることは、別の打ち手です。前者だけを追いかけると、不要な作業を高速に生産し続けることになりかねません。速くした先に何を置くかも、はっきりしていました。 「無駄を省くことで生まれたバッファーは、顧客の声を拾う時間などに有効活用して、より良い、求められるものを作り出していきたいです」 今回の取り組みの対象になった案件そのものが、顧客の声から生まれたものでした。 顧客の声を聞く → 作る → その時間を捻出するために速くする → さらに顧客の声を聞く。 AI活用を、開発効率の話で終わらせず、顧客志向のサイクルを回す原資として位置づける。ここに、ラクスの開発組織がAIに向き合う理由が表れているように感じます。 まとめ 今回の取り組みから持ち帰れるポイントを、3つに整理します。 AI活用の伸びしろは、まだAIが入っていない工程にある。 導入済みのところを磨くより、AIが入っていない場所を探すほうが伸びしろは大きい 書き直しが確定している成果物は、AIとの相性が良い。 速さだけでなく「修正しても整合性が壊れない」ことの価値が効いてくる フェーズに応じて、品質の妥協ラインを決める。 仕様が動く段階で作り込んでも、その労力は次の書き直しで消える ラクスの開発本部では、「顧客に価値を高速提供できるAIネイティブな開発組織へ」という方針のもと、こうした現場発の試行錯誤を各チームで進めています。今回のように、まだAIが入っていない領域に踏み込む取り組みも、これから増えていくはずです。 最後までお読みいただきありがとうございました！

こんにちは。2026年4月にラクスに入社し、楽楽精算開発部に配属された木村です。 この記事では、入社してから実務に入るまでの約4ヶ月間に受けた研修の内容と、配属後の研修中に学んだことを書きます。ラクスのエンジニア職に興味がある方のご参考になれば幸いです。 研修の内容は年次によって変わる可能性があるため、ご注意ください。 なぜラクスを選んだか 入社から実務に入るまでの流れ 新入社員合同研修 技術研修 配属後研修（楽楽精算） 配属後研修で得た気付き おわりに なぜラクスを選んだか ラクスを選んだ理由の1つは、若手にも挑戦の機会がある環境だと判断したからです。 就職活動では、若手にも挑戦の機会があるかを重視していました。やったことのない仕事に挑戦することで、できることを増やしていきたいと考えていました。選考の際、面接の逆質問を通して若手の挑戦機会について直接確認できたことが、入社を決める後押しとなりました。 入社後に社員の方とお話しする中で、実際に成果を出した若手が新しい役割やプロジェクトを任された事例を本人や周囲の方からお聞きしました。年次に関係なく成果を出していれば挑戦の機会を与えてもらえる環境なのだと改めて実感しました。 入社から実務に入るまでの流れ 入社から実務に入るまでのスケジュールは以下の通りです。 期間 内容 4/1 - 4/10 新入社員合同研修 4/13 - 6/30 技術研修 7/1 - 9/11 配属後研修 配属後研修の期間は目安です。配属時の経験や知識によって、研修期間は前後します。 以降でそれぞれの研修について説明していきます。 新入社員合同研修 ビジネスマナーなど社会人としての基礎に加え、就業規則や人事制度といった社内の制度、クラウドサービスのビジネスモデルや各プロダクトについて学びます。 今年は生成 AI 活用研修がありました。生成 AI の特徴と社内で利用できる AI の説明から始まり、 Gemini とNotebookLM（現Gemini Notebook）のハンズオンがありました。最後に Gemini の Canvas 機能を使ってアプリを作るハッカソンがありました。Gemini は学生のときから使っていましたが、Canvas 機能でアプリを作れることまでは知りませんでした。 技術研修 約2ヶ月半、エンジニア職の新卒全員で受ける研修です。Webアプリケーションの設計から運用保守までの一連の開発プロセスを実践できるようになることを目指した内容になっています。具体的な学習内容は以下の通りです。 カテゴリ 内容 IT基礎 ハードウェア基礎、ネットワーク基礎 Java プログラミング入門、Collection API、ラムダ式、Stream API、例外処理 オブジェクト指向 クラス、継承、委譲、カプセル化、インターフェース、ポリモーフィズム、SOLID 原則 データベース RDBMS、SQL、JDBC、Entity と DAO パターン Webフレームワーク Spring Boot、Thymeleaf、DI コンテナ、Spring JDBC フロントエンド HTML/CSS、JavaScript、jQuery、Ajax による非同期処理、React テスト ソフトウェアテスト入門、JUnit、TDD バージョン管理 Git AI駆動開発 プロンプト、Design Doc、ADR セキュリティ SQL インジェクション、XSS 運用保守 パフォーマンスチューニング、ロギング インフラ Linux、シェルスクリプト、Docker、Apache & Tomcat 連携、デプロイ AI 駆動開発は今年から追加された内容です。Claude Code のようなコーディングエージェントを使う研修ではなく、コンテキストエンジニアリングの講義でした。仕様と意図を Design Doc、ADR、Javadoc として書き出し、それらをプロンプトとともに Gemini へ渡してコードを生成させるという内容でした。実装しながら設計や仕様を固めていくスタイルに慣れていたので、先に仕様を文書化してから生成させる進め方には苦戦しました。AI を使いこなすためには、開発スタイルを変えていく必要があると感じました。 これらの学習と並行して、朝の時間に技術発表か小テストがありました。技術発表とは、担当者が特定のテーマについて勉強したことを発表する取り組みです。1周目は『リーダブルコード』、2周目は技術や用語の説明でした。 研修の最後にはチームで EC サイトを開発しました。商材はいくつか用意されていましたが、今年は全チームが独自の商材を扱う EC サイトを開発しました。私たちのチームは編み物のキットを商材に選びました。ただ、チームに編み物の経験者がいなかったため、機能のアイデアは出せるものの、それが実際に使われるものなのか判断できませんでした。そこで、編み物の経験がある同期や、編み物の専門店で働いている方にインタビューを行い、曲がりなりにも根拠を持って仕様を決めていくことができました。 これは実際のプロダクト開発でも同じではないかと思います。顧客への解像度が低いまま作った機能は価値として届きません。根拠がないまま議論を続けても結論は出ず、リリースも遅れます。ラクスが顧客志向を重要視する理由が少し分かりました。 配属後研修（楽楽精算） 楽楽精算の開発に必要な技術やドメイン知識を学ぶ研修です。主に以下のことを学びます。 楽楽精算の機能 楽楽精算で利用されている技術 楽楽精算のシステム構成 最後に楽楽精算に機能を追加する課題に取り組みます。学習メニューの詳細は2022年の記事でも紹介されているので、こちらをご覧ください。 tech-blog.rakus.co.jp 変わった点としては、資格の取得が任意になったこと、サポートサイト課題の負担が減ったことがあります。楽楽精算のサポートサイトには「フムフム」という AI チャットボットが導入されています。以前はサポートサイトのほぼ全ページを読む必要があったようですが、チャットボットのおかげで知りたい情報をピンポイントで入手できるようになりました。 配属後研修で得た気付き ここでは、楽楽精算に機能を追加する課題で学んだことを書きます。 同期のプルリクエストに LGTM（Looks Good To Me）を返した後、メンターの方から以下のようなコメントを頂きました。 “ LGTMと判断したレビュー観点をリストアップして貰えますか？ ” 1行消して1行足すだけのプルリクエストだから、そんなに時間はかからないだろうと思い、レビューの観点を書き出すと、思いの外、手が止まりました。同期が書いた値の意味は理解していましたが、なぜその値にするのかまで説明できませんでした。その値がどこでどう使われているのかを調べ直すことになり、返信までに20分以上かかりました。 自分も同じ課題をやったはずなのに、なぜ理由を説明できなかったのか。自分なりに考えた結果、実装時に自ら判断する機会を作らなかったからだという結論に至りました。 自分で実装する場合、何を書くかを自分で選ぶ必要があります。選ぶ以上、なぜその値にしたのかという理由が自分の中に残ります。一方、AI に実装を任せると、すでに選ばれた状態のコードが出てきます。出力を読んで確認はしますが、なぜ他ではなくその値なのかを考えなくても先に進めてしまいます。今回の課題でも、なぜその値にするのかまで踏み込めていなかったため、理由を説明できませんでした。 AI を活用するのが当たり前となった現代において、すべてを自分で実装するのは現実的ではありません。AI に実装させる前提で、なぜその実装にしたのか自分で判断する機会を意図的に設ける必要があることを学びました。 おわりに 約4ヶ月の研修を通じて、技術面はもちろん、プロダクト開発における顧客志向の重要性や、AI を活用した実装において自ら判断を下す必要性など、実務に通じる気付きを得ることができました。 判断する機会の必要性について、現時点で明確な解決策を持っているわけではありません。これから実務が始まるので、日々の業務の中で試行錯誤しながら、実装の理由を見失わない進め方を見つけていきたいです。 この記事が、ラクスのエンジニア職に興味がある方のご参考になれば幸いです。

こんにちは！楽楽精算開発部 の yamaguchi877 です。 「保守開発チーム」と聞くと、障害発生時の地道な調査やお客様からの問い合わせ対応に追われる姿を想像される方が多いかもしれません。 ですが私たちのチームでは 問い合わせの切り分けと一次調査をAIエージェントに任せる 仕組みを構築・運用し始めています。 本記事では、その仕組みづくりで直面した 「AIの判定を毎回同じにするにはどうすればいいのか」 という壁を紹介しつつ、 私たちなりの答え（固定ルーブリック＋回帰テストという設計）とあわせて、構想から運用までの試行錯誤をご紹介します。 抱えていた課題 — 問い合わせ対応と開発時間の綱引き 全体像 — 楽楽販売からGitHub Issues、そしてAIエージェントへ 最大の壁 — AIの判定は「毎回同じ」にできるのか 回帰テストでプロンプトを守る エージェントは分業制 — そして無理な自動化はしない AIがAIのルールを改善する — ただしガードレール付きで つまずきポイント — GitHub Actionsのifでハマった話 これから — 完全自律型エージェントへの道 最後に 抱えていた課題 — 問い合わせ対応と開発時間の綱引き 私たち保守開発チームは、主に以下の4つをメインタスクとして日々を過ごしています。 お客様からの問い合わせ対応 外部連携システムのアップデート対応 楽楽精算内部の不具合対応 他チームへの知見共有 このうち一番迅速性が求められるのが、お客様からの問い合わせ対応です。 問い合わせは、CSが社内の管理システム（楽楽販売）に起票し、エンジニアが内容を切り分けて調査・回答する流れで届きます。 種類の見極め、類似事例の確認、ログや設定の調査——1件ずつは小さくても、積み重なれば調査工数は膨らみ、開発に充てる時間を圧迫します。 さらに、問い合わせ対応の体制見直しにより、エンジニアが受け持つ問い合わせの範囲は今後さらに広がる見込みでした。 何も手を打たなければ、開発時間が削られるのは目に見えていました。 この「工数増」を打ち消す切り札が、 問い合わせの切り分けと初期調査をAIエージェントに任せる 仕組みです。 切り分け・初期調査をAIで即時に走らせ、エンジニアは判断と最終確認に集中する。 そうしてお客様への回答リードタイムを短縮する——これがこの取り組みで狙う顧客価値です。 全体像 — 楽楽販売からGitHub Issues、そしてAIエージェントへ 仕組みの全体像はこうです。 全体像 起票部分は完全に固定作業になるためPythonのスクリプトにしています。 今はこの部分からAIに任せてしまうことも考えられますが、今後はAIによるトークン消費のコスト意識も必要になると考え、固定作業はスクリプトにしています。 AIによる最大のメリットを享受するためには、「何をAIに任せるか」の線引きも大事だと感じています。 最大の壁 — AIの判定は「毎回同じ」にできるのか トリアージとは、Issueを読んで「誰が調査すべきか」をラベル（仕様・不具合調査／環境構築／クレジットカード関係／不明など）で切り分ける作業です。 AIに任せるにあたり、最初は素朴に「Issueを読んで適切なラベルを付けて」とAIの裁量に任せるプロンプトを書いていましたが、実行するたびに判定が微妙にブレていました。 試行錯誤の末にたどり着いたのが、 AIの裁量を徹底的に排除する という方向性でした。 具体的には分類ルールを次の形式で記述しています。 分類ルール 内容 狙い 順序固定の判定手順 Step 1：「このIssueの主目的は『◯◯してほしい』だ」と一文に要約する Step 2：クレジットカード判定 Step 3：環境構築判定 → … 必ずこの順番で実行させ、途中のStepを飛ばさせない 判定の経路を毎回同じにする トリガー語句の表 「構築してほしい」「原因を知りたい」など、 判定の決め手になる語句を表で列挙し、表への一致で判定させる 言い回しの解釈をブレさせない 固定の確信度ルーブリック 確信度は85/70/50/40/30の5値のみ 70以上でラベル付与、70未満は「不明」として人間に返す 確信度の数値をブレさせない たとえばこんなトラップ事例があります。　　 「〇〇の連携の不具合に伴う環境構築依頼」　　 上記のような題名のIssueがあった時、主目的は環境構築なのに、「不具合」の文言に引っ張られ、モデルによっては「仕様・不具合調査」へ誤分類されていました。 分類ルールを通せば、Step 1で主目的が「構築」と確定し、「不具合」は背景の語句として扱われます。 その結果、モデルや実行タイミングに左右されず、「環境構築・インフラとのやりとり」に機械的に決まるようになりました。 「ここまでルールを固定するなら、ただのif文でなんとかなるのでは？」と思われるかもしれません。 ですが、無限にある言い回しをif文で網羅するのは現実的ではありません。かといって、判断基準そのものはAIに委ねない。　　 ルールを記述・保守するのは人間、言い回しの揺れを吸収してルールに当てはめるのはAI 　　 この分担が肝となりました。 回帰テストでプロンプトを守る そしてもうひとつ、個人的に一番の学びだったのがこれです。 プロンプトも、コードと同じように回帰テストで守ることができる。 分類ルールを変更したら、過去の確定事例を集めた事例集に対してテストモードで再判定を走らせます。 全件一致を確認してから、変更を確定する 運用にしています。コードのリファクタリングでテストを回すのと同じ感覚です。 これを始めてから、「ルールを直したら別のケースが壊れた」という事故を未然に防ぐことができるようになりました。 また、GitHub Actionsで動く自動経路のモデルもコストと再現性のため固定しています。 エージェントは分業制 — そして無理な自動化はしない エージェントは、人間のチームと同じ「分業制」にしています。1人の万能選手を作って回すのではなく、役割を絞った担当を連携させ、個々の精度を上げる。 そして手戻りを減らし、業務全体を安定して速く回すことを第一目標としているためです。 エージェント 役割 トリアージ担当 Issueを読み、依頼種別と後続エージェントを判断する 調査担当 アプリ仕様・DB定義・過去依頼を調査し、根拠と未確認事項を整理する SQL作成担当 確認用・実行用SQLとレビュー観点を作成する SQL稼働確認担当 作成されたクエリのレビューと稼働確認までを自動で実施する 報告資料担当 調査結果やSQLを統合し、報告用Markdownにまとめる エージェントを分けたことによるメリットは、大きく3つあります。 それぞれのエージェントに渡す指示とコンテキストを小さく保てること 間違えたときに「どこで間違えたか」がすぐ分かること 工程の間に人間が介入できるポイントが生まれること 確信度70未満を「不明」として人間に返す設計も同じ思想です。 自信を持って判定できるものだけAIに捌かせ、迷うものは人間が判断する。そして人間が付けた正解ラベルは、AIの判断基準を改善する材料として蓄積させることができます。 AIがAIのルールを改善する — ただしガードレール付きで 上記のような運用を続けると、AIの自動判定と人間が最終的に付け直したラベルの間にズレが蓄積していきます。 このずれを取り込むための「最適化エージェント」も用意しています。判定履歴と人間の最終ラベルを突き合わせて誤分類のパターンを分析し、分類ルールと事例集の改善案を作ります。AIがAIのルールを改善するループです。 ただし、ここにも三重のガードレールを敷いています。 エージェントが直接適用できるのは 事例集への追記のみ 分類ルール本体の最終変更は 回帰テスト合格後 にのみ適用 不要になった事例の削除は 人間の判断 で行う 「AIによる自己改善」は聞こえがいいですが、無条件に回すとルールが静かに壊れていくリスクがあります。 改善のループは回しつつ、確定の権限は人間と回帰テストが握る。このバランスが現時点での私たちの落としどころです。 つまずきポイント — GitHub Actionsの if でハマった話 最後に、恥ずかしい失敗談をひとつ。 Issueへのラベル付与をトリガーに自動トリアージを起動するworkflowで、誤爆防止のガードをこう書いていました。 if : github.event.label.name == env.ENGINEER_REQUEST_LABEL 一見動きそうですよね。ところがこのガード、 一度もマッチしませんでした 。GitHub Actionsの仕様で、jobレベルの if では env コンテキストが参照できません（使えるのは github / needs / vars / inputs のみ）。 そのため env.ENGINEER_REQUEST_LABEL が空文字に評価され、常にfalseになっていたのです。 原因究明の末、ラベル名はリテラルで直接書く形に落ち着きました。 if : >- github.event_name == 'workflow_dispatch' || github.event.action != 'labeled' || github.event.label.name == 'エンジニア依頼' AIでなんでも書けている気になって、基礎も押さえず実装していたため、「なぜか自動起動しない」を追いかけた時間は、なかなかのものになってしまいました。同じ轍を踏む方が一人でも減れば幸いです。 これから — 完全自律型エージェントへの道 現在、トリアージの自動実行は試験運用中で、日々小さな更新を行っています。 依頼を検知してから報告までの自動化を最終目標に、段階的な移行を進めており、トリアージの先の各パートでも、チームメンバーがそれぞれ検討を進めています。 以下、検証のざっくりした方針です。 仕様・不具合調査の精度向上 Issueを読み取り、ソースコードを元に原因の一次調査を行う 原因箇所と発生条件を調査レポートとして生成し、ユーザーに通知 必要であればクエリ自動作成に繋げる クエリ自動生成の高度化 顧客調査が必要な問い合わせに対し、クエリ作成を行う SELECT系クエリ、UPDATE系クエリごとにPRを作成するリポジトリを選択 自動でクエリ稼働確認に繋げる クエリ稼働確認の自動化 テスト対象クエリに対し、クエリの記述ミスや不整合を検出するためのテストデータを自動生成 検証環境へ自動接続し、対象クエリの配置およびテストデータの展開を実施 クエリを自動実行し、実行結果を収集・フィードバック 最後に 保守開発チームの仕事は、派手さはないかもしれません。 ですが今回取り組んだ問い合わせ対応の原点は、「お客様の困りごとに、早く正確に答える」ことです。 そこに立ち返ると、AIエージェントの活用はこれ以上ないほど相性の良い挑戦だと感じています。 ラクスの開発本部は「AIネイティブな開発組織」への変革を進めています。 この取り組みもその一環で、AIを前提に業務フローそのものを再設計する挑戦だと捉えています。 同じように問い合わせ対応の工数に悩むチームの、何かのヒントになれば嬉しいです。最後までお読みいただきありがとうございました！

こんにちは、楽楽販売開発課のdon （頓花）です。 あるサブシステムをゼロから設計する機会があり、ADR（Architecture Decision Record／アーキテクチャ上の意思決定を記録するドキュメント）を書く場面が一気に増えました。 そこで Claude Code を検討プロセスそのものに組み込んでみたのですが、最初に作った仕組みは、実際に走らせてみるとひどいものでした。エージェントが 1 体で 約60分 動き続ける。工程の境界でユーザー確認が 20 回近く飛んでくる。レビューが 3 巡目に入ってもう何も新しい指摘が出ない。 この記事は、そこから何を直したかの記録です。 この記事で分かること 自分の検討プロセスを工程に分解して Skills に移植する手順 マルチエージェント構成で「全員が会話に参加し続ける」構成をやめた理由 前提情報をリポジトリに置いて AI に読ませる運用 動かしてみて初めて分かった、重い箇所の潰し方 【目次】 足りないのは AI の賢さではなかった 前提: 3 つの仕組みを使い分ける まず、自分が ADR を考える流れを分解する 工程をオーケストラ Skills ＋専門エージェントで構成 全員呼ばない、1 回に集約する 試行錯誤①: 全工程エージェントチームから、サブエージェントへ変更 試行錯誤②: 前提情報を AI が読める形に整理 試行錯誤③: ログを見て Skills 自体を改善 効果と、いまの課題 効果 課題 ADR 以外への応用 まとめ 参考リンク 足りないのは AI の賢さではなかった ADR に AI を使おうとすると下記のようなことがよく発生します。 ひとつは 単発チャット地獄 です。毎回ゼロから前提を説明し直す。「このプロダクトはこういう構成で、過去にこう決めていて……」と貼り直すだけで疲れて、本題に入る前に力尽きます。 もうひとつは 丸投げ です。「いい感じに ADR 書いて」で出てくるものは、形式は整っているのに検討が浅い。観点の抜け漏れが残り、レビューで結局やり直しになります。 どちらも AI の能力の問題ではありませんでした。足りていなかったのは、 自分の検討プロセスを AI が再現できる形にすること でした。 そしてこれは、単に開発が楽になるかどうかの話ではありません。AIへ委譲する割合を増やすことで並列で作業ができるようになり、開発速度を上げることができるようになります。 前提: 3 つの仕組みを使い分ける 本題ではないので手短に触れます。Claude Code には次の 3 つの仕組みがあります。 Skills : 「こういうときはこう進める」という手順書を Claude Code に持たせる仕組み サブエージェント（subagent） : タスクを独立したエージェントに渡し、結果だけ受け取る。呼ばれたときだけ動作するため、呼び出し元の文脈を汚さずに実施できる仕組み エージェントチーム（Agent Teams） : 複数のエージェントが互いにメッセージを送り合って議論する仕組み 。全員が会話に参加し続ける のが特徴 ※ 詳細は公式ドキュメントを参照: Skills ／ subagents ／ Agent Teams まず、自分が ADR を考える流れを分解する AI に渡す前にやったのは、 自分の頭の中の工程を言語化する ことでした。ここを飛ばして skills を書き始めると、結局「いい感じに」と書いてあるだけの手順書になります。 ADR 検討を、動詞ベースで次の工程に分けました。 前提固め → 計画 → 案出し →（検証）→ 独立評価 → 合議 → ドラフト化 →（実装） 工程 要否 やること 前提固め 前提・スコープ境界・完了条件をユーザーと対話して合意する。 既存の決定・仕様・API 定義もここで走査する 計画 この論点ではどの専門家を呼ぶか、どこまでやるかを決める 案出し 選択肢を出し、各案を最新の一次情報で詳細に調べる 検証 任意 判断に動作確認が要るなら、使い捨ての PoC を作る 独立評価 専門家が各自 独立に 案を評価する（あえて合議させない） 合議 出そろった評価をもとに方針を確定する ドラフト化 ADR 本体を書く 実装 任意 採用案を試しに実装する 設計時に気にした点は2点です。 先頭の「前提固め」で、人間の判断を最初に組み込む。 ここでスコープ境界と完了条件をこちらが合意します。後工程がいくら賢くても、前提がずれていれば的を外した ADR が出てくるだけです。 明確にステップを区切る。 これにより作業ごとにコンテキストを分けられるためトークンの節約やコンテキスト肥大化の抑制につながります。 工程をオーケストラ Skills ＋専門エージェントで構成 分解した工程を、ひとつの大きな Skills（オーケストラ役）が指揮し、工程ごとに専門エージェントを呼ぶ構成にしました。 編成は次のようになっています。読者のみなさんが自分のプロセスに置き換えるときの参照にしてください。 区分 体数 役割 モデル 指揮役 1 計画を立て、呼ぶ専門家を選ぶ 重め 調査・案出し役 1 前提の下調べと選択肢の整理 軽め 集約・執筆役 1 議論をまとめ ADR をドラフト 重め 検証役 1 使い捨て PoC（任意工程） 軽め 常駐レビュアー 1 全工程に伴走し観点を採点 軽め 反論役（Devil's Advocate） 1 必ず 1 件以上の反論・Blocker を出す 軽め 領域別の専門家 5 言語 2・DB・API 契約・Python 系 軽め 横断的な専門家 4 運用・インフラ・クラウド・セキュリティ 軽め プロダクト知見の専門家 1 既存プロダクトとの整合・移行・業務観点 軽め 横断ルールのチェックリストを常駐レビュアーの必須参照にし、逸脱を Blocker として報告させ、事例を追記して育てる循環 進行を指揮する役と、最後に決定をまとめる役だけ重いモデルを割り当てています。ここは判断の質が成果物に直結するためです。それ以外は軽いモデルで十分でした。 全員呼ばない、1 回に集約する エージェントを 16 体も定義すると、素直に組めばコストが爆発します。抑えるために入れた工夫が 4 つあります。 専門家を毎回全員呼ばない。 指揮役が論点を分類し、必要な数体だけ起動する。 （ex: DB の話が出てこない ADR に DB の専門家は不要なため起動しない。） 専門家の起動を 1 工程に集約する。 同じ専門家を案出しから実装まで何度も叩き直さず、独立評価の工程で 1 回だけ評価させます。 重いレビューはドラフト工程の 1 回だけにする。 別系統のレビューを挟むのは仕上げの手前だけです。 常駐の 2 体は工程ごとに起動して破棄する。 常駐レビュアーと反論役は全工程に伴走しますが、チームとして常駐させるのではなく、工程ごとにサブエージェントとして呼び直しています。 エージェントを増やすのは簡単ですが、実際に重いのは「どの工程で、どの論点のときに呼ぶか」を決める作業のほうでした。 試行錯誤①: 全工程エージェントチームから、サブエージェントへ変更 最初は 全工程をエージェントチームでやろうとしました 。 複数の専門家が議論しながら設計を詰める構成にしました。理論上はコンテキストも節約しながら進められる想定でした。 しかし、実際には全員が会話に参加し続けるので コンテキストが急速に肥大 し、評価が出そろう前から議論が混線するようになりました。それによりそれぞれの主張が曖昧になり、セッションが長くなりトークン消費量も増大しました。 （ Claude Code でMaxプランの5時間制限の30%近くを1セッションで消費しました。） そこで構成を切り替えました。 既定はサブエージェント方式 にする。独立に呼び出し、結果はファイルで受け渡す。 合議の工程も、まずは指揮役が評価を読んで直接まとめる 方式を既定にする。 エージェントチームは明示的に指定したときだけ 使う（重い論点で本当に対話が要るケース） 試しに同じタスクを比較すると、セッションの稼働時間が改善後（サブエージェント案）は改善前（エージェントチーム）の 約 1／3 になりました。 ※ ただしこれは 1セッションのみ での計測結果です。 得られた教訓は「マルチエージェント＝エージェントチームを常用する」ではなかった、ということです。 対話が本当に要る工程だけチーム、それ以外は独立したサブエージェント という使い分けが、コンテキスト効率に効きました。 もっともこれは私のケースでの結果です。エージェントチームの使い方を詰めれば別の最適点があるはずで、エージェントチーム自体が悪いという話ではないと考えてはいます。 試行錯誤②: 前提情報を AI が読める形に整理 手順（Skills）が良くても、 前提が無ければ検討は浅くなります 。専門家エージェントに「このプロダクトならこの方針」という前提が無いと、教科書的な一般論しか返ってきません。 そこで前提情報を 4 カテゴリに整理して、コンテキストとしてAIに明示的に渡すようにしました。 プロダクトの特性・大方針 既存の決定 : 決定済みのADR のリスト 横断ルールのチェックリスト : 承認済みの ADR で確定した設計判断のうち、議論で逸脱されやすい項目だけを 1〜数行に圧縮 調査方針 : 学習データの記憶に頼らせず、案出しのたびに最新の一次ソースの調査を必須化 3 番目のチェックリストは、実際の失敗から生まれました。 たとえばマルチテナントのデータ分離方式を「スキーマを分ける」と決めていたとします。ところがエージェントは、論点が変わるたびに「識別カラムを持たせる方式ではどうか」と提案してきます。一般論としては妥当な案なので、毎回それらしい理屈がついてきます。決定済みの前提が渡っていないと、こうした「もっともらしい差し戻し」が延々と発生します。 これを毎回人間が指摘して回るのは無理があります。そこで確定事項をチェックリストにまとめ、 常駐レビュアーと反論役の必須参照 にしました。逸脱を見つけたら Blocker として報告させる、という構造的な対策です。 このチェックリストは、逸脱事例を観測したら都度追記する運用にしています。最初から完璧なものは書けないので、育てる前提で置いています。 試行錯誤③: ログを見て Skills 自体を改善 Skills を書いて終わりにはできませんでした。実際に ADR を通して走らせ、ログを見て重い箇所を 1 つずつ潰しました。 実走で見えた問題 直した内容 単発で 約60分 動き続けるエージェント 出力件数・文字数・想定時間に上限を設ける 工程の境界でユーザー確認が 約20回 既定で自動進行にし、Blocker 検出時だけ停止する レビューが 3巡目 で空転 レビューは2巡までとし、超えたらユーザーに引き継ぐ 通しで走らせた後に「これ ADR で扱う話？」となる事故 冒頭に適格性ゲートを1問だけ置く とくに 2 番目は、自分で書いた Skills に「条件付き自動進行」と謳っておきながら、実際は毎境界で確認を飛ばしていたという間抜けな話です。動かしてみるまで気づきませんでした。 4 番目も同じです。ドラフトまで通した後に「これは ADR ではなく機能方針の話では？」と自分で疑問を持ってしまった。なので最初に「本件は ADR で扱うべきか」だけを 1 問聞き、そうでなければ別の進め方を提案して終わる、というゲートを置きました。 ここで狙ったのは平均時間の短縮ではなく、 極端に重いケースを抑えること です。約 60 分動き続けるエージェントが 1 体いれば、平均がどうであれ体験は破綻します。 効果と、いまの課題 効果 体感として得られたものは 3 つあります。 前提の貼り直し回数が低減 毎回の説明から解放され、検討の中身に時間を使えます。 浮いた時間は、業務課題そのものを理解する側に回せるようになりました。 観点の欠落が低減 反論役が必ず 1 件以上の反論を出すので、後工程で気づいて手戻りする回数が減りました。 AI同士の議論が建設的に 変更前はAI同士の議論が追認会になることがありましたが、 独立評価 → 合議の順にしたことと、合議には反対の立場を持つメンバーを必ず 1 名入れるようにしたことにより建設的な議論になった。（気がします。） 課題 一方で課題も残っています。 効果は体感どまりで、定量的な比較ができていない 前提チェックリストや上限設定の効果は、再実走で検証待ち ADR 専用で、機能要件や詳細設計は対象外 ADR 以外への応用 ここまで ADR を例に書きましたが、同じ型は「検討プロセスを持つ仕事」全般に使えるはずです。実装設計、技術選定、障害の振り返りなど、頭の中に工程がある仕事ならどれも当てはまります。 共通する型はこうです。 プロセスを分解する → 工程を Skills 化する → 前提を AI が読める形にする → 対話が要る工程だけチームにする まとめ AI に丸投げするのでも、単発質問を繰り返すのでもなく、 自分の検討プロセスを移植する 。これが今回いちばん効いた考え方でした。 AI に任せる範囲を広げることが AI ネイティブな進め方だと思っていましたが、実際は逆でした。 人が判断する場所を先に決めるほど、残りを安心して任せられる 。冒頭に「前提固め」を置いたのは、まさにそのためです。 最初の一歩は Skills を書くことではありません。 まず自分が普段どう考えているかを書き出してみること です。 それを Skills に移植し、試し、改善していくことによってAIによる効率化を進めていくことができると思います！ 参考リンク Claude Code 公式ドキュメント Extend Claude with skills Create custom subagents Agent teams

はじめに 先に用語を固定します 結論から：これは「検証の積み木モデル」です 第1層：LLM単発推論 — 検証がない世界 第2層：ReAct — 「できたか」を自分で確認する 第3層：ループエンジニアリング — 合否判定を、作った本人の外に出す これ、人間がやってた作業ですよね ただし、1つの成果物の中では判定できないものがある 第4層：グラフエンジニアリング — 目的適合の検証と、ループ同士の配線 なぜ抽象度が上がっていくのか 自己流の判断基準 まとめ 参考 はじめに AIエージェント開発課のKazuki Kanekoです。 ここ数ヶ月、「ループエンジニアリング」や「グラフエンジニアリング」という言葉を見かけることが増えました。 ループエンジニアリングは2026年6月に出てきた言葉 グラフエンジニアリングは2026年7月に出てきた言葉 どちらも生まれて数ヶ月で、定義もまだ固まっていません。新しいワードが注目されると「ループの時代は終わったのか、これからはグラフか！」となりがちです。私も最初は、新しいのが出たので学んでみようというスタンスでした。 ただ、いろいろ触って考えた結果、今はこう捉えています。 ループとグラフは別物ではありません。「出力の品質を、誰が、どう検証するか」の抽象度を一段ずつ上げてきた、包含関係です。 この記事では、この捉え方を私なりに整理して共有します。 ※この記事は2026年8月時点の、私の理解の整理です。厳密な系譜や歴史の解説ではありません。 先に用語を固定します 本題に入る前に、ひとつだけ注意点があります。 「グラフ」という言葉は、文脈によって指すものが違います。 実行制御のグラフ ：LangGraphのように、エージェントの処理の流れをノードとエッジで設計するもの コンテキストのグラフ ：GraphRAGのように、LLMに渡す知識をグラフ構造で持つもの この2つは別レイヤーの話ですが、どちらも「グラフ」と呼ばれるので混ざりがちです。この記事で扱うのは 前者（実行制御のグラフ） です。 結論から：これは「検証の積み木モデル」です 先に結論の図を出します。 ループエンジニアリングの中では、ReActループが回っています。グラフエンジニアリングの中では、ループエンジニアリングで組んだループが回っています。 外側の層は内側の層を置き換えるのではなく、包んでいるだけ です。 では、層が上がるごとに何が変わっているのか。私は「検証」に注目すると一番すっきり整理できると思っています。 層 検証されるもの 合否を判定する主体 人間から引き継いだ役割 第1層 LLM単発推論 出力そのまま 人間（仕組みの外） — 第2層 ReAct タスクが完了したか LLM自身（自己申告） 「次に何をするか」を決める作業者 第3層 ループエンジニアリング 1つの成果物が、事前に決めた合格基準を満たしているか 実行した本人とは別の判定器（テスト / Lint / スキーマ、または評価用LLM） ログを読んでNG理由を伝えるレビュアー 第4層 グラフエンジニアリング 複数の成果物が互いに整合し、本来の目的に沿っているか 合流点に置いた上位の判断（強いモデル or 人間） 複数の作業を調停するマネージャー つまり各層がやっているのは、 それまで人間が担っていた検証の役割を、一段ずつ仕組みに肩代わりさせること です。第1層では検証の仕組みが一切なく、判定主体は仕組みの外にいる人間でした。 ここから、各層を順に見ていきます。 なお、この記事の図は色を統一しています。 🟦 青 ：LLMが動くノード（推論・エージェント実行） 🟩 緑 ：検証・分岐・人間の承認（品質を担保するポイント） ⬜ グレー ：入出力・外部リソース 同じ色を追っていくと、 外側の層に行くほど緑（検証）の比重が増えていく のが見えると思います。 第1層：LLM単発推論 — 検証がない世界 出発点はここです。LLMに1回プロンプトを投げて、1回答えが返ってくる。 良いプロンプトを書く（プロンプトエンジニアリング） 良い文脈を渡す（RAG、のちのコンテキストエンジニアリング） 工夫のしどころは「入力」でした。 この図に緑（検証）のノードは1つもありません。 出力が正しいかどうかを確かめるのは、100%人間の仕事 です。出てきたものを人間が読んで、ダメなら人間がプロンプトを直して投げ直す。検証と再実行のループを、人間が手で回していた、とも言えます。 第2層：ReAct — 「できたか」を自分で確認する 考える → ツールを使う → 結果を見る → また考える を繰り返す形。いわゆるReActパターンです。 第1層との決定的な違いは、 緑のノードが初めて登場した ことです。「タスクは完了したか？」という検証を、LLMが自分でやるようになりました。人間が担っていた「次に何をするか決めて、できたか確認する」という作業者の役割が、ループの中に取り込まれたわけです。 Claude CodeやDevinのようなコーディングエージェントの「エージェントらしさ」も、中心にあるのはこのループです。 ただし、ここでの検証には弱点があります。 自己申告 だということです。「完了したか？」を判定しているのは、その出力を作った本人（LLM）です。テストを書かずに「動きました」と言ってくるエージェントを見たことがある人なら、この検証だけでは品質を担保しきれないことを体感していると思います。 第3層：ループエンジニアリング — 合否判定を、作った本人の外に出す そこで出てくるのが、2026年6月にGoogleのAddy Osmani氏が広めた「Loop Engineering」です。 Osmani氏の整理では、ループエンジニアリングとは「仕事を発見し、エージェントに配り、結果を検証し、進捗を記録し、次の仕事を決めるシステム」の設計です。 私の言葉で言い直すと、こうなります。 第2層の自己申告を信用せず、合否判定を「それを作った本人の外」に出す層 です。テストやLintのような決定的な判定器が典型ですが、ルーブリックを渡した評価用LLMに採点させるのも同じ構造です。重要なのは判定器が機械かどうかではなく、 出力した本人が自分で合格を宣言していない ことです。 図の真ん中に、第2層のReActループが青いノードとしてまるごと入っていることに注目してください。ループエンジニアリングはReActを置き換えていません。 包んで、外側に検証と再実行の仕組みを足している だけです。 これ、人間がやってた作業ですよね この層が肩代わりしているのは「レビュアー」の役割です。 たとえば、エージェントが出力したコードが失敗したとき、私はAWSのCloudWatchのログを見に行って、「これがNGの理由っぽいですよ」とエラーログをエージェントに貼り付けて再実行させる、という作業をよくやっていました。 ループエンジニアリングの「Fail → 失敗ログをフィードバックとして次の入力に含めて再実行」は、 まさにこの人間の作業をモデル化したもの だと捉えています。 合否の判定：人間が目で見る → テスト / Lint / スキーマ検証が機械的に判定する NG理由の伝達：人間がログをコピペする → 失敗ログを自動でコンテキストに含める 再実行の判断：人間が「もう一回やって」と言う → 停止条件（試行回数・予算）の範囲で自動リトライ エージェントの賢さに期待するのではなく、 検証と再実行の仕組みで品質を担保する 。モデルが十分賢くなったからこそ、「中の推論」より「外側の回し方」が差別化要因になった、とも言えます。 ただし、1つの成果物の中では判定できないものがある 第3層の検証は強力ですが、判定できるのは そのループが作った1つの成果物の中で閉じる問い だけです。 「この実装方針で良かったのか？」なら、まだ第3層で戦えます。判定器を強いモデルに変えて、設計方針をレビューさせればいい。 機械的な基準に落ちないこと自体は、第3層を降りる理由になりません。 第3層で本当に手が出ないのは、 複数のループの成果物をまたぐ問い です。 実装ループの出力とドキュメントループの出力が、食い違っていないか 個々のタスクは全部Passしたのに、束ねたら 当初の目的からずれていないか これらは、どちらか一方のループの中からは見えません。判定を下すには、複数の成果物が合流した地点が要ります。 その合流点を作る層が第4層です。 第4層：グラフエンジニアリング — 目的適合の検証と、ループ同士の配線 2026年7月頃から「ループの次はグラフでは？」という議論が始まりました。きっかけはPeter Steinberger氏の「Are we still talking loops or did we shift to graphs yet?（まだループの話してる？それとももうグラフに移った？）」というポストと言われています。当時私もこのポストを見て「グラフってなんだ？」と疑問を抱いた記憶があります。 私はグラフの関心事を、2つに分けて捉えています。 1つ目は、合流点でしかできない検証です。 複数のループの出力を1か所に集めて、互いに整合しているか、束ねた結果が本来の目的に沿っているかをレビューする。判定するのは相当賢いモデルか、承認ノードとして入る人間です。第3層と違うのは判定器の賢さではなく、 判定に必要な材料が1つのループの中に揃わない という点です。 2つ目は、配線です。 ループが複数になると、実行順序・依存関係・失敗時の戻り先を明示的に設計しないと破綻します。たとえば「実装ループが終了しないと、テストループは動き出せない。テストループは実装ループの成果物を受け取る」という依存関係。あるいは「検証NGだったら、どのノードまで戻すのか」という戻り先。この配線図がグラフです。冒頭で触れたLangGraphは、まさにこの配線（ノード・エッジ・共有状態）を実装するためのフレームワークで、Google ADKやMicrosoftのAgent Frameworkにも同様の仕組みがあります。 ここでも注目してほしいのは、青いノード「ループA」「ループB」の中身が 第3層で設計したループそのもの だということです。グラフはループを置き換えていません。第3層で品質担保されたループを部品として、その外側に「合流」「目的適合の検証」「戻り先」を配線しているだけです。 そして、失敗系のエッジ（自動検証NG、人間の差し戻し、例外）がすべて計画ノードに戻っていることも、この層の性格をよく表しています。第3層のFailは「同じタスクをログ付きでリトライ」でしたが、第4層のFailは「そもそも計画からやり直す」。 検証の抽象度が上がると、差し戻しの抽象度も上がる わけです。 なぜ抽象度が上がっていくのか ここまでを振り返ると、層が積み上がる理由が見えてきます。 第1層には検証がなく、品質担保は100%人間の仕事だった 第2層で「完了したか」の検証をLLMに任せた。ただし自己申告なので信用しきれない 第3層で合否判定を、作った本人の外に出した。ただし1つの成果物の中で閉じる問いしか判定できない 第4層で、複数の成果物をまたぐ検証を、合流点に置いた上位の判断（強いモデル or 人間）に任せた つまり、 今の検証手段では判定できないものが現れるたびに、一段外側の検証層が生まれている 。これが、私がこの積み重なりの軸を「検証の抽象度」とした理由です。 そしてどの段も、やっていることの本質は同じです。 人間が担っていた検証の役割を、仕組みに肩代わりさせる。 作業者（第2層）、レビュアー（第3層）、マネージャー（第4層）と、置き換える役割の抽象度が上がってきただけです。 自己流の判断基準 この層の見方に立つと、「どのアーキテクチャを選ぶか」は「どの層まで登る必要があるか」という問いに変換できます。私が使っている判断基準を、まずフローチャートで示します。 以下、Q1から順に補足していきます。 Q1. そもそもエージェントが必要か？ 経路が完全に事前に決められるなら、LLMを呼ぶ関数を順番に実行するだけのワークフローで十分です。安く、速く、確実です。→ 必要なら Q2 へ。 Q2. 合否判定を、作った本人の外に出せるか？ テスト、Lint、スキーマ検証で判定できるなら、そのまま第3層です。機械的な基準に落ちない場合でも、合格条件をルーブリックとして書き出せて、別のモデルに採点させられるなら、これも第3層です。 ここで第4層に飛ぶ必要はありません。 逆に、合格条件を言語化すらできず、毎回人間が現物を見ないと判断できないなら、それは層を上げて解決する問題ではありません。まずは合格条件を言語化する作業のほうが先です。→ Q3 へ。 Q3. その検証は、1つの成果物の中で閉じるか？ 閉じるなら第3層のままでいけます。実装とドキュメントの整合、複数タスクの成果を束ねた後の目的適合など、 複数の出力を突き合わせないと判定できない なら、合流点が必要になるので第4層です。→ Q4 へ。 Q4. 失敗したとき、戻り先は1つか？ 「同じタスクを、失敗ログを添えてやり直す」だけで済むなら第3層で十分です。停止条件を超えたときのエスカレーション先が人間になるのは第3層でも普通で、これは層を上げる理由になりません。 一方、「これは実装からやり直し、これは計画からやり直し」と 戻り先が複数に分かれる なら、どこへ戻すかを明示的に描く必要があります。その戻り先の一覧がグラフです。→ Q5 へ。 Q5. 状態は1つのコンテキストに収まるか？ タスクが長く、複数の専門性が必要で、1つのコンテキストで持ちきれないなら、複数のループへの分割を検討します。ただし、分割した瞬間に依存関係と戻り先の設計、つまり配線が必要になるので、これも第4層のグラフが必要になります。 Q3・Q4・Q5がすべてYesなら、第3層で止めてください。これが推奨の初期形です。 むしろ多くのタスクは、Q2をYesで抜けた時点で完成します。 ポイントは、グラフが最新だから、グラフにしようとならないこと です。 上の段は、下の段の検証では管理しきれなくなった複雑さを整理するための道具です。その複雑さがまだ無いのに導入すると、設計コストだけ払うことになります。 第3層のループで始めて、管理しきれなくなったら第4層に昇格させる。これが今のところ私の結論です。 まとめ ループエンジニアリングとグラフエンジニアリングは 別物ではなく、包含関係 です 各層がやっているのは、 人間が担っていた検証の役割（作業者→レビュアー→マネージャー）を仕組みに肩代わりさせること です 今の検証手段で判定できないものが現れるたびに、一段外側の検証層が生まれます 選び方は「どの層まで必要か」。 判定を本人の外に出せて、その判定が1つの成果物で閉じるならループ。複数の成果物を突き合わせる必要があるか、失敗時の戻り先が複数に分かれるならグラフ です そして、 いきなりグラフから始めない 。ループで始めて、必要になったら昇格させます この分野は数週間単位で前提が変わります。この記事の整理も、半年後には自分でアップデートしている気がします。そのときはまた、整理し直した記事を書こうと思います。 最後に、この記事の立ち位置を書いておきます。世間の「グラフエンジニアリング」の議論は、複数のエージェントを並列に動かすマルチエージェント組織の設計、という切り口で語られることが多い印象です。この記事の「検証の抽象度」という軸は、それとは別の切り口です。どちらが正しいという話ではなく、定義がまだ固まっていない言葉だからこそ、自分の設計判断に使える形で捉え直してみた、というのがこの記事です。 実際、私はこの捉え方を「新しいアーキテクチャを追いかけるための地図」ではなく、「いま作っているものは、どの層の検証で品質を担保できるか」を問うための、設計判断の1つの軸として使っています。 自分の整理も兼ねて、記事を執筆しました。ループとグラフを語る上での一つの軸として持ち帰って頂ければ幸いです。 参考 Addy Osmani, "Loop Engineering: Designing loops that prompt coding agents"（2026年6月8日） https://addyo.substack.com/p/loop-engineering （O'Reilly Radar転載版： https://www.oreilly.com/radar/loop-engineering/ ） Peter Steinberger氏のポスト（2026年7月18日） https://x.com/steipete/status/2078277297791189132 Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models"（2022年） https://arxiv.org/abs/2210.03629

こんにちは、ラクス技術広報です。 2026年7月15日、主催イベント「RAKUS AI Conference 2026 Summer」を開催しました。本記事では、楽楽精算 開発3課の平川裕多さんが発表した「仕様駆動開発、導入半年。『本当に速くなってるの?』にデータで答える」について、技術広報がレポート記事でご紹介します。 この記事はこのような方におすすめです AI活用で実装は速くなった気がするのに、なぜか設計やレビューの負荷が増えていると感じているエンジニアの方 仕様駆動開発(SDD)の導入を検討している、あるいは導入したものの効果を数字で説明できずに悩んでいる方 「AIネイティブな開発」を、感覚ではなくデータで語りたいと考えているエンジニアの方 【目次】 「それ、本当に速くなってるの?」に答えられなかった半年 仕様駆動開発に"飛びついた"というのが実態でした 上司とメンバーからの"ツッコミ"と、1年分のデータを掘る決意 データを掘って初めて分かった、3つの指標の意外な共通点 指標①：時間 指標②：レビュー 指標③：バグ（事故） 3つの指標から見えてきたもの 正直に語られた課題と、「仕様を決める力」への投資 終わりに 「それ、本当に速くなってるの?」に答えられなかった半年 平川さんのチームが担当するのは、経費精算クラウドサービス「楽楽精算」のモバイルアプリです。iOS、Android、バックエンド、フロントエンドという複数のプラットフォームを、6名のエンジニアがアジャイルの2週間スプリントで開発しています。 ここ1〜2年でAI活用が本格化し、個人の実装スピードは体感としても数字としても間違いなく上がったといいます。コードを書く作業は、以前ほど開発のボトルネックではなくなりました。 ところがその裏で、3つの問題が起きていました。 意図のよく分からないコードが混ざるようになったこと レビューの負荷に偏りが出るようになったこと テストフェーズになって初めて「考慮漏れ」に気づく事故が多発するようになったこと 設計段階で気づかず、後工程で発覚するほど、修正のコストは高くつきます。 「早くはなったけど、何か別のものを払っている感覚があった」 この違和感から生まれたのが、「AIで早くなった裏で、本当は何を払っていたのか」という問いでした。 仕様駆動開発に"飛びついた"というのが実態でした この問いに対して、平川さんたちがたどり着いたのが仕様駆動開発(SDD)でした。ただし、最初からSDDを狙って導入したわけではなかった、と平川さんは振り返ります。 最初にやっていたのは、今まで手で書いていた設計書をAIに書かせて時短できないか、という「AI設計テンプレート」的な試みでした。それを1ヶ月ほど地道に作り込んでいたそうです。ちょうどそこに、世の中で「仕様駆動開発」という言葉が流行り始め、「これ、自分がやりたかったやつだ」と思ったといいます。慎重に比較検討して選んだというより、飛びついたという感覚の方が実態に近いと振り返ります。 飛びついたあとで、あらためて「なぜ他のやり方ではなくSDDだったのか」を整理しました。 Planモード ：AIがタスクを組んでくれて便利だが、結局それを使うエンジニア個人の能力に依存する点で、直接指示と本質的に変わらない テスト駆動開発(TDD) ：リファクタリングには強いが、そもそも仕様がブレていればテスト自体が空中分解してしまう Planモードの質もTDDのテストの質も、たどっていくと結局は「仕様」に行き着く。だったら一番上流の「仕様」そのものを中心に据えるのが筋が良い、という腹落ちだったとのことでした。 具体的には、マークダウンで構造化した自然言語の仕様書を使い、設計そのものをPRとしてレビューする運用を敷きました。とはいえ、自然言語の成果物にはコードのようなリンターもテストも効きません。「問題ない」と判断するにはしっかり読む必要があり、コストがかかります。仕様を構造化したり重複を減らしたりという地味なチューニングを、今も積み重ねている最中とのことでした。 上司とメンバーからの"ツッコミ"と、1年分のデータを掘る決意 SDDを始めてすぐ、突っ込まれる日々が始まりました。 上司からは「それ本当に早くなってるの」「設計に時間をかけている分、トータルで遅くなっているんじゃないの」という声。メンバーからは「設計フェーズが大変になった」「一番頭を使う部分が重くなった」という声が上がりました。 この2つのツッコミに、感覚で「いや、早くなっていますよ」と返しても説得力がありません。そう考えた平川さんは、1年分のデータを本気で掘り返して検証することにしました。 なお、平川さん自身「そもそもSDDを品質のために入れたわけではなく、狙いは実装を誰がやっても同じ質にして属人性をなくすことだった」と前置きしています。この後の検証結果は、当初の狙いとは別のところで平川さんたちを驚かせることになります。 データを掘って初めて分かった、3つの指標の意外な共通点 AIもアジャイルも定着した時期以降のデータに絞り、フェアな比較を心がけたうえで、3つの指標を見ていきます。 指標①：時間 実装フェーズの数字は、確かに速くなっていました。ただし、その「速さ」の正体を追うと、後工程にあった意思決定の負荷が、設計フェーズに前倒しされただけでした。たとえば「複数ある実装方針のどれを採用するか」という判断は、SDD以前は実装しながら決めることもありました。今はそれを設計のタイミングで行います。AIが選択肢を出してくれる分、考えるのは楽になった場面はあるものの、最終的にどれにするかを人間が決め、レビューやステークホルダーの合意を得る必要がある点は変わりません。SDD自体は時短策ではない、というのが平川さんの見立てです。 指標②：レビュー 1つのPRあたりの他者からのコメント数は、中央値がずっと1でほぼ横ばいでした。レビューの総量そのものは減っていません。ただし中身は変わっていました。実装PRで「この仕様どうなってるの?」という揉め事が減り、その議論が仕様レビューの場に前倒しされたのです。レビューが純粋なコード品質チェックに近づいたという意味では狙い通りですが、「楽になった」わけではなく、「議論する場所が移った」というのが実態に近い、と平川さんは説明します。 指標③：バグ（事故） バグの発生件数そのものは、劇的には変わっていませんでした。ただし2つの変化がありました。1つは、1件あたりの対応時間（※着手からテスト完了までのリードタイム）が17時間から11時間に短縮したこと。もう1つが、平川さんいわく「これが大きい」変化でした。以前は1スプリントで20件を超えるような"バグの大爆発"が起きることがあったのが、最大でも8件程度に収まるようになりました。事故の数ではなく、事故の振れ幅が小さくなったということです。 なお、この集計はテストまで完了したスプリントのみを対象にしており、サンプル数はまだ多くありません。平川さん自身、断定ではなく傾向として見てほしいと、数字の限界を率直に語っていました。 3つの指標から見えてきたもの 3つの指標を並べると、見えてくるものがあります。時間もレビューも、内容は移っただけで総量は変わらず、バグは件数こそ横ばいながら振れ幅が縮みました。 ここから導かれる結論を、平川さんはこう言い切ります。「SDDの本当の成果は、速さじゃない」。開発そのもののスピードは、AIをガムシャラに使っていた1年前とほとんど変わっていません。得られたのは、予測可能性でした。裏を返せば、以前ガムシャラに速度を出していた頃、代わりに払っていたのは、この予測可能性だったのです。 平川さんはこれを具体的なエピソードで語っていました。怖いのは、バグ修正にかかる時間そのものより、「何件出るか読めないこと」だそうです。2週間スプリントの7日目まで予定通り進み、残業もせず帰れていたとします。それなのにテストでバグがたくさん出ると、残り数日で焦って対応するか、別スプリントに送るかという判断に迫られ、計画が崩れます。SDDによって仕様の検討が上流に寄った結果、この「予想外の大爆発」が起きにくくなったのです。平均的な件数は大きく変わらなくても、最悪のケースが消えて振れ幅が縮み、立てた計画が、そのまま計画として機能するようになりました。 そしてこれは、働きやすさだけの話ではありません。事故で開発が止まらないということは、顧客に安定したペースで価値を届け続けられるということでもあります。予測可能性は、顧客への価値提供の土台でもある。平川さんはそう位置づけていました。 正直に語られた課題と、「仕様を決める力」への投資 SDDは時短の手法ではなく、決めごとの総量も変わりません。それでも品質と予測可能性への投資だった、というのが平川さんの結論です。実装スピードそのものは変わらなくても、速さの出方が変わりました。昔は事故が起きるかどうか読めないまま勢いで速度を出していたのに対し、今は上流で足場を固めてから、同じ速度を読める形で出している。アジャイルを捨てたわけでもなく、2週間スプリントという枠のなかで「決める位置」を前にずらしただけだ、という整理も印象的でした。 ここで終われば美談ですが、平川さんは課題も正直に語っていました。時間もレビューも総量は「移っただけ」で減ってはおらず、総量そのものをどう減らすかは宿題のままです。さらに、レビューを上流に寄せた結果、今度は仕様レビューの方が渋滞するという新しいボトルネックも生まれています。 興味深かったのは、仕様が設計段階で固まることで、そこからテストを作るのも楽になるという発見です。固まった仕様を起点にすれば、テスト設計やユニットテストを考える時間も減り、AIに任せられる部分も増えます。上流で固めた仕様を、テスト作成の自動化にそのまま流し込む。この接続を今まさに模索しているそうです。 またメンバーの「設計フェーズが大変」という声の実体は、仕様書を作ったあとのモブレビューではなく、その前段階、個人がローカルで仕様を練っている時間が最も頭を使う、というものでした。ここに「ループ」や「ハーネス」といった仕組みを当てはめ、機械的に拾える考慮漏れはモブレビュー前に潰しておきたいとのこと。ただし、モブレビューそのものは残したいとも話していました。人を育てる場であり、テックリード一人がすべてをレビューしなくても、メンバー同士でレビューが回るようになる効果もあるからです。自動化するのは生成の負荷にあたる部分で、人間の判断や育成の機会は残す。この線引きを大切にしているとのことでした。 この先の展望として、平川さんは「ループエンジニアリング」という考え方も紹介していました。海外のAI開発ツールの責任者が「もうAIに指示は出していない、自分の仕事はループを書くことだ」と話しているそうで、その考え方の提唱者とされる人物も「これは仕事が簡単になったわけではなく、レバレッジの効く点が移っただけ」と釘を刺しているとのことでした。これは平川さんが今回データで語った「決める場所が上流に移っただけ」と、驚くほど重なる指摘です。その人物はさらに、全部を自動ループに任せればプロダクトの品質は落ちるとまで話しているそうです。つまりループは「何が正解か」の判断までは代わってくれません。その「何が正解か」を上流ではっきりさせるのが、まさにSDDです。ループの時代が来るほど、その前段にある「仕様を決める力」の価値は上がっていく。開発をAIに委ねても、「何が正解かを決めるカロリー」だけは人間に残る、という見方を示していました。 予測可能性が手に入るということは、AIに安全に任せられる範囲が見えてくるということでもあります。読めないものは任せられませんが、振れ幅が小さく読めるものなら任せられます。その範囲を安全に広げていけば、いずれボリュームが増え、トータルのリードタイムも縮んでいくはずです。平川さんは、今回手に入れた予測可能性を、その先の自動化を安全に広げるための「足場」だと位置づけていました。 終わりに 時短にはなっていない、新しいボトルネックも生まれた。それでも正直に数字と向き合う姿勢そのものが、AIネイティブな開発組織のリアルなのだと感じます。「なんとなく速くなった気がする」で終わらせず、データで自分たちの仮説を裏切る勇気を持てるかどうか。仕様駆動開発を検討している方にとって、平川さんの検証プロセスそのものが参考になれば幸いです。 当日の発表資料はSpeakerDeckで公開しています。ぜひあわせてご覧ください。 発表資料 speakerdeck.com なお、8月下旬ごろに発表のアーカイブ動画をラクスエンジニア情報ポータルサイトにて公開予定です。 ラクスエンジニア情報ポータルサイト career-recruit.rakus.co.jp 「RAKUS AI Conference 2026 Summer」の他レポート記事 ・ AIを載せることはゴールではない。ラクスCTOと開発副本部長が語った、組織とプロダクトの変革 ・ 顧客の声から生まれた『AI返信補助機能』の開発プロセス ・ 楽楽精算AIエージェントを支える、LLMOpsとインフラの選択肢 ラクスでは、こうした「顧客志向」と「AIネイティブ」の両方を大切にしながら、地に足のついた検証を重ねる開発組織を、一緒に作っていく仲間を募集しています。ご興味を持っていただけた方は、ぜひ採用ページもチェックしてみてください。 最後までお読みいただきありがとうございました！

こんにちは、ラクス技術広報です。 2026年7月15日に開催した主催イベント、「RAKUS AI Conference 2026 Summer」の5本のセッションのうち3本目に登壇したのが、AIエージェント開発課の竹田舜さんです。 テーマは「PoCから本番へ―楽楽精算AIエージェントを支える、LLMOpsとインフラの選択肢」。 CTOや役員による組織戦略の話に続き、現場のエンジニアが実際に何を判断してきたのかという、解像度の高い知見が語られたセッションでした。竹田さんが語ったのは、「AI専用の特殊なものというよりは、慣れているもの、知見のあるものを優先して素早く構築しました」という意思決定です。 この記事はこのような方におすすめです AIエージェントをPoCから本番運用へ進めようとしている、あるいはこれから進めようとしているエンジニアの方 AI専用の新しい基盤(AgentCoreなど)を採用すべきか、使い慣れた技術で構築すべきか迷っている方 【目次】 AI専用の基盤を採用する前に、まず問うべきこと β版からの学びを生かした有償版における顧客志向を体現した改善 「見えないAI」を、見える化する 顧客に価値を届け続けるための、地に足のついた選択 AI専用の基盤を採用する前に、まず問うべきこと 竹田さんが担当するのは、2025年12月にβ版を、2026年6月16日に正式版をリリースした、経費精算クラウドサービス「楽楽精算」に組み込まれた「伝票作成AIエージェント」です。領収書を選択し、カードや事前申請などの紐付けデータを選べば、あとはAIにお任せ。伝票ができあがると通知が届き、最後は人がチェックしてそのまま申請する。 楽楽精算初のAIエージェント機能です。 このエージェントを支える実行基盤として、当初は4つの選択肢が挙がっていたといいます。Lambda、ECS、そして開発の途中で登場したAgentCoreのようなAI専用のマネージドサービス、そしてEKS。少人数体制と開発速度を最優先するという制約のなか、竹田さんたちが選んだのはEKSでした。なかでも意見が割れたのはECSとEKSの間で、最終的にはキャッチアップコストの低さと、CIなど既存資産をそのまま活用できる点からEKSを選んだといいます。 「AI専用の特殊なものというよりは、慣れているもの、知見のあるものを優先して素早く構築しました」 理由は明快です。社内にはすでにKubernetes運用の資産とノウハウが蓄積されていて、キャッチアップにかかる時間はほとんど問題にならない。検証環境もオンプレミスでほぼ同等に再現できる。目新しいAI専用基盤に惹かれる場面もあったはずですが、「使い慣れた道具で確実に前へ進む」ことを選んだ判断は、AIエージェント開発の技術選定に悩む読者にとって、一つの参考軸になるのではないでしょうか。 CD(Continuous Delivery: 継続的デリバリー)基盤にも同じ思想が貫かれています。ArgoCDとGitHub Actionsという、社内に知見が蓄積された組み合わせを採用。GitHub Actionsによる自動化とArgoCDの分かりやすいUIによって、「最低限の操作を覚えれば、Kubernetesに詳しくないエンジニアでもリリース作業が可能」になり、オンボーディングコストの低下にもつながったといいます。万一リリースに失敗した際も、ArgoCDのUI上ですぐに気づけるため、Kubernetes有識者へのエスカレーションもスムーズです。 サービス構成は、マネージドサービスとOSSのハイブリッドです。サービス分割の基準は「スケーリングが必要か」「技術の変化が速いか」「コア機能かどうか」の3点。ストレージや監視のように自チームでの運用負荷が高くなりがちな部分には、マネージドサービスを積極的に採用しました。 「プロジェクト開始当初は、ある程度の正解すら分からない状態でした。だからこそ、後からでも要因を切り分けて変更できる構成にしました」 竹田さん自身、「当時ベストだったかは難しい」としつつも、「ベターと言える判断」だったと振り返ります。完璧な正解を最初から追い求めるのではなく、変更可能性を残した意思決定を積み重ねる姿勢は、正解の見えないAIプロダクト開発における実践知の一つだと感じました。 β版からの学びを生かした有償版における顧客志向を体現した改善 β版から正式版への道のりで、竹田さんが一番大きな改善として挙げたのが、KEDA(Kubernetes Event Driven Autoscaling)の導入です。 伝票作成エージェントは、LLM呼び出しなど時間のかかる処理を非同期化しています。当初はこの非同期処理を、キューにメッセージを保管しておき、定期的にメッセージの有無を確認して一定数ずつ処理する、ポーリング方式で実装していました。処理数は一定数で固定しており、1バッチで処理しきれなかった分は、次のバッチ処理に回す仕組みです。 この際、「メッセージ処理数」と「バッチ間隔」のバランスの見極めが悩みどころでした。間隔を短くすればキャパシティオーバーのリスクが高まり、長くすれば顧客を待たせ、UX悪化に繋がります。さらにタイミングによっては、バッチの狭間に入ったリクエストが次のバッチの最後まで待たされてしまう、UXにムラのある状態が生まれていました。 「無駄なくキャパシティオーバーせずに使いたい。リソースに余裕があるときは、即座に近い状態でリクエストに反応したい」 この課題に対して導入されたのがKEDAです。伝票作成エージェントでは、Kubernetesのジョブ単位でもスケーリングできる性質を活かし、キューの件数に応じたジョブ起動数の制御を実現しました。 KEDA導入によるポイント キューの件数に応じてジョブ起動数を比率で制御(例:キュー4件→ポッド2つ起動) 定期実行からリアクティブなイベント駆動アーキテクチャへ転換 マニフェストで運用できるため、既存のKubernetes運用との親和性を維持 これにより、キャパシティオーバーの可能性は下がり、即時反応によって顧客を待たせるリスクも減りました。派手な機能追加ではなく、地道な実装の工夫でユーザー体験を磨き続けた好例だと言えるでしょう。 「見えないAI」を、見える化する 竹田さんが最後に強調したのが、Observability(可観測性)への投資です。「監視は後回しにされがちですが、最初から手をつけてきました」という言葉どおり、伝票作成エージェントではトレース・メトリクス・ログという3種類のテレメトリーを、OpenTelemetry CollectorとFluent-bit経由でAWSのマネージドサービスへ集約する基盤を構築しています。 なぜここまで力を入れるのか。サービスが分割されている以上、処理を追うには分散トレースが欠かせません。また、AIエージェントは複雑かつ不確実に動作するため、何が起きているかの詳細を追う必要があります。AIエージェントの非決定的な振る舞いは「同じエラーでも原因が異なる」ことが珍しくありません。ログのメッセージだけでは判別しづらい不具合の原因究明に、トレースが役立っているといいます。 コストとのバランスも工夫のしどころです。サンプリング率は対象によって使い分けているとのことでした。 対象 サンプリング率 理由 LLM呼び出し関連のトレース 100% 利用状況・モデル利用状況の把握に必須 エラー系トレース(ステータスがエラー/未設定) 100% 障害調査に必須。全体量としても許容範囲 通常トレース(現在) 5% コストを抑えつつ傾向を把握 通常トレース(サービスが不安定だった初期) 70%程度 安定するまでは決め打ちで多めに取得 最初から5%だったわけではなく、安定するにつれて段階的に絞り込んでいったというプロセスが印象的でした。メトリクス収集は、CloudWatch Agentではなくコンテナインサイトレシーバー経由でOpenTelemetry Collectorを利用することで、フィルタリングによるコスト最適化と、環境に応じた柔軟なサンプリング調整を両立させています。ログについては、CloudWatchとS3を保管場所として併用し、利便性とコストのバランスを取っています。このように三種のテレメトリについて、初期からコストを考慮した構成にしています。 こうして蓄積したトレースやログは、監視のためだけでなく次の一手にもつながっています。失敗内容を分析し、推論・ツール呼び出し・バリデーションのどこでつまずいたのかを特定します。顧客からの問い合わせと類似の失敗パターンが見つかった場合は、顧客データそのものは使わずに、原因を再現するダミーデータセットを作成してオフライン評価の改善に役立てているとのことでした。 さらに、現在のオフライン評価に加えてオンライン評価からのフィードバックループの構築や、評価ピラミッドによるテストスコープの整理、評価軸の体系化にも取り組んでいるそうです。 これらはAIエージェント開発課の専任メンバーが中心となって進めており、伝票作成エージェント単体の改善にとどまらず、いずれは全社で使えるプラットフォームとしての整備も見据えているといいます。 顧客に価値を届け続けるための、地に足のついた選択 竹田さんの発表を振り返ると、そこにあったのは「AI専用の目新しい技術を追いかける」姿勢ではなく、「使い慣れた技術で確実に前に進み、実装の工夫で顧客体験を磨き、監視への投資で信頼性を担保する」という、地に足のついた意思決定の積み重ねでした。 この姿勢は、ラクス開発本部が掲げる「顧客志向×AIネイティブな開発組織」という方向性そのものだと感じます。AIネイティブとは、目新しい技術をとにかく採用することではなく、顧客に価値を届け続けるために、既存の資産とAIなどの新しい技術を適切に組み合わせていく選択の連続と言えます。伝票作成AIエージェントの裏側にある技術選定は、その実践の一つの形ではないでしょうか。 「本番運用を任せられるAIエージェントをどう作るか」に悩むエンジニアの方にとって、竹田さんの判断軸が何かのヒントになれば幸いです。 当日の発表資料はSpeakerDeckで公開しています。ぜひあわせてご覧ください。 発表資料 speakerdeck.com なお、8月下旬ごろに発表のアーカイブ動画をラクスエンジニア情報ポータルサイトにて公開予定です。 ラクスエンジニア情報ポータルサイト career-recruit.rakus.co.jp 「RAKUS AI Conference 2026 Summer」の他レポート記事 ・ AIを載せることはゴールではない。ラクスCTOと開発副本部長が語った、組織とプロダクトの変革 ・ 顧客の声から生まれた『AI返信補助機能』の開発プロセス ・ 仕様駆動開発、導入半年。「本当に速くなってるの?」にデータで答える ラクスでは、こうした「顧客課題の解決」に真剣に向き合うAIエージェント開発に一緒に取り組む仲間を募集しています。ご興味を持っていただけた方は、ぜひ採用ページもチェックしてみてください。 最後までお読みいただきありがとうございました！

2026年7月15日、オンラインイベント「RAKUS AI Conference 2026 Summer」を開催しました。本記事では、その中の1セッション「顧客の声から生まれた『AI返信補助機能』の開発プロセス」（登壇：楽楽自動応対AI開発課 四方大輔さん・今井陸斗さん）の内容を、技術広報がレポート形式でまとめます。 「作ったのに使われないAI機能」、心当たりはありませんか 半年間、精度を上げ続けてもお客様の声は変わらなかった 顧客に直接聞いて分かった、担当者が本当に困っていたこと 「メール作成AI」から「メールアシスタント」への方向転換 ドキュメントではなく「動くもの」でお客様と議論する あった方がいいはずの機能が、実は「邪魔」だった AIプロダクト開発で大切な3つのこと エンジニアの仕事は「実装する」から「お客様を理解する」へ speakerdeck.com 「作ったのに使われないAI機能」、心当たりはありませんか AI機能をリリースしたものの、思ったほど使ってもらえない。精度を上げても上げても、現場からの評判は変わらない。AIプロダクト開発に携わるエンジニアであれば、一度はこうした壁にぶつかったことがあるのではないでしょうか。 今回紹介するのは、楽楽自動応対開発チームが、まさにこの壁にぶつかり、そこから立て直していった実例です。結論を先に言ってしまうと、このチームが学んだのは以下の3点でした。 お客様の業務フローを知らずに機能を作ると、使われない機能ができあがる AIで動くPoC（試作品）を即座に作り、ドキュメントではなく「動くもの」で議論する 機能の要・不要を決める「正解」は、現場のお客様だけが知っている この3点は楽楽自動応対に限った話ではなく、AIを使ったプロダクト開発に取り組むエンジニアなら誰でも実践できる考え方だと感じています。以下、実際に何が起きたのかを時系列で見ていきます。 半年間、精度を上げ続けてもお客様の声は変わらなかった 楽楽自動応対は、問い合わせメールをチームで一元管理し、過去の対応履歴を資産として活用しながら応対業務を効率化するクラウドサービスです。主にカスタマーサポートなど、メールを多く扱う現場の担当者に利用されています。 2025年10月、このサービスに「メール作成AIエージェント機能」がリリースされました。受信メールを読み取り、過去の類似の問い合わせを参照しながら、AIが返信文案を自動生成するという機能です。リリース前には精度検証を行い、ビジネスサイドと「使い物になる」ラインをすり合わせた上での公開でした。 ところが、リリース後の利用率は思っていたほど上がりませんでした。ビジネスサイド経由で聞こえてくるお客様の声は「精度が悪い」「使えない」「手で書いた方が早い」というものが多く、なかなか厳しい現実に向き合うことになったといいます。 当時は本番環境でAIがどう振る舞っているかを継続的に追う仕組みが整っておらず、プロンプトの改善やロジックの見直し、モデルの切り替えといった、いわば小手先の精度改善を重ねる日々が続きました。しかし、それでも「使えない」という声は減らず、気づけば半年が経過していたそうです。 顧客に直接聞いて分かった、担当者が本当に困っていたこと 根本的に改善するには、まず現場で今何が起きているかを知る必要がある。そう考えたチームが取った行動は、素直にお客様に話を聞きに行くことでした。 登壇した四方さんは楽楽自動応対の開発を10年近く担当しており、当初はドメイン知識も顧客理解も十分にあるつもりだったといいます。しかし実際にお客様の声を聞く中で、「お客様が実際にどうメール応対業務を行っているか」を全く理解できていなかったことを痛感したそうです。 具体的に見えてきたのは、次のような実態でした。メールの応対業務は一般的にいくつかの工程からなるフローで進みますが、AIが担当するようになったのは「作成」の工程だけでした。AIが作った文面をそのまま使うかというと、多くの担当者はやはり信用しきれず、必ず内容を確認します。つまり、AIで作成を楽にしたつもりが、確認という新たな手間を生み、かえって担当者の負荷を上げてしまっていたのです。 さらに、メール応対はいわゆるフロントオフィス業務であり、メールの品質がそのまま顧客体験の品質に直結します。だからこそ「AIに丸投げする」という発想自体が、現場の感覚とズレていたことも見えてきました。同時期に行われた市場調査でも同様の声が上がっており、「メールを自動生成する」という機能の前提そのものが、お客様に求められていなかったのではという疑いが確信に変わっていったといいます。 「AI活用やAIエージェントというのは、突き詰めればお客様の業務をAIに置き換えることだと考えていたはずなのに、その当たり前ができていなかった」と四方さんは振り返ります。 「メール作成AI」から「メールアシスタント」への方向転換 信用してもらえないという声に応えるため、チームはAIが本文をいきなり自動生成するのではなく、返信を組み立てるための材料を提示する方向へと舵を切りました。コーディングエージェントの「プランモード」に近い発想です。 具体的には、メールの内容を読み取って要点を示したり、類似の過去問い合わせを探したり、大量にあるテンプレートの中から適したものを提案したりと、担当者の作業そのものをAIが肩代わりするのではなく、担当者の判断をAIがサポートする形へと機能を再設計していきました。 とはいえ、AIプロダクト開発において「何を作れば使われるか」が最初から明確なケースは多くありません。「ざっくり楽にしたい」「なんとなく自動化したい」といった、ふわっとした要望から出発することがほとんどだと四方さんは言います。このメールアシスタント機能への転換時も、必要な機能は何か、情報を見せすぎるとかえって読まれなくなるのではないか、といった議論が社内で白熱したそうです。 最終的にたどり着いたのは「正解はお客様に聞くしかない」という発想でした。そして、その正解に最速でたどり着くために取ったアプローチが、後半で紹介する開発プロセスの変革です。 ドキュメントではなく「動くもの」でお客様と議論する 後半のセッションを担当した今井さんは、開発プロセスそのものの変革について紹介しました。 これまでの開発は、ビジネスサイドが要求資料を作成し、それに沿って開発側が要件をすり合わせ、仕様が固まってから実装するという進め方でした。この方法では、実装が完了するまで実際の動きが見えづらく、デザインモックだけでは確認しきれない部分が残ります。結果として、実装後にビジネスサイドへ触ってもらって初めて「なんとなく違う」というフィードバックが出て、手戻りが発生することも少なくありませんでした。 そこで今回は、最初から動くものを仮で作る「PoCファースト」のアプローチを取ったといいます。これを可能にしたのは、AIの進歩によってコーディングの大部分を指示ベースで任せられるようになったことが大きいと今井さんは説明します。PoCの作成にはClaude Codeを活用し、あくまで仮の実装であることを前提に、保守性やコードの綺麗さよりもスピードを優先する、いわゆるバイブコーディングで進めたそうです。 さらに、ビジネスサイドとの検討で「必要かもしれない」と挙がった機能は取捨選択せず、いったんすべてPoCに盛り込みました。実装のほとんどをAIに任せられるため、機能数が多少増えても実装コストがそこまで膨らまない、という判断があったからこそ取れた選択です。 そして重要なのは、このPoCをビジネスサイドだけでなく、実際に機能を使うことになるお客様にも直接見せたという点です。「不要かもしれない」という機能が本当に不要かどうかは、社内の議論だけでは決められません。現場を知るお客様に判断してもらうのが最も確実だと考えたからです。 あった方がいいはずの機能が、実は「邪魔」だった 実際にお客様へPoCを見せた結果は、チームの想定とは異なるものでした。 当初、メールアシスタント機能にはメール本文の要約や、質問に対する回答方針の提示など、返信に役立つと思われる機能を一通り盛り込んでいました。しかしお客様に見せてみると、要約や回答方針があってもAIの回答が100%正しいとは限らないため、結局は本文や過去のやり取りを自分の目で確認する必要があり、時短にはつながらないという意見が返ってきました。「あった方がいい」と思っていた機能が、実際には「邪魔」だった、という気づきです。 一方で、返信に使うテンプレートの提案機能や、作成した本文に対する添削機能は「使える」という評価を得られました。 ターゲットについても発見がありました。当初は返信業務を行うユーザー全員を対象に機能を検討していましたが、経験豊富なベテラン担当者にとっては、AIが出してくる情報を追加で確認する手間がむしろノイズになってしまうという声が上がりました。一方、メール作成に不慣れな新人担当者にとっては、テンプレートを探す時間や、作成したメールを先輩に確認してもらう時間を減らせるという利点が明確でした。この結果を踏まえ、ターゲットは「全ユーザー」から「新人担当者」へと絞り込まれました。 お客様と実際に対話し、業務フローを理解できたからこそ、このようにターゲットを変える判断ができたと今井さんは振り返ります。 AIプロダクト開発で大切な3つのこと 今井さんは、今回の経験から見えてきた学びを、楽楽自動応対に限らずどのようなエンジニアでも実践できるものとして、3点に整理していました。 1. お客様の業務フローを知ること 作ろうとしている機能がどう使われるかを知らずに開発すると、使われない機能ができあがる可能性が高くなります。無駄な機能を作らないためには、まずエンジニア自身がお客様の業務を把握することが欠かせません。 2. AIを使って動くPoCを即座に作ること ドキュメントや文章ベースで議論するよりも、実際に動くものを見ながら議論した方が認識のずれが生まれにくく、圧倒的に効率的です。この段階では機能を絞り込まず、思いつくものはすべて載せて、いったん全体を見える状態にしてから議論することが有効だといいます。 3. できあがったPoCを、実際に使うお客様に見てもらうこと 機能が使えるか使えないかの「正解」を持っているのは、現場を知るお客様です。答えのない状態でビジネスサイドと開発側だけで議論するのではなく、正解を知っているお客様に判断してもらう。この段階で不要な機能を見極めておけば、リリース後の手戻りも減らせます。 エンジニアの仕事は「実装する」から「お客様を理解する」へ 今回の事例のポイントは、開発プロセスを変えたことで開発スピードが上がった、という話に留まりません。AIに実装を任せることで生まれた余白の時間を、お客様と向き合う時間に転換できたことこそが本質だと今井さんは強調していました。 お客様と対話することで、実際に機能が使われる場面への解像度が上がり、より良い機能開発につながります。しかも一度きりではなく、機能をブラッシュアップするたびに繰り返し対話することで、方向性が合っているかを都度確認できるようになったといいます。お客様の業務フロー理解とフィードバックの解消をエンジニア自身が担うことで、エンジニアの仕事は「機能を実装するもの」から「機能を考えるもの」へと、上流にシフトしつつあると感じている、というのが今回のセッションの結びでした。 ラクスが大切にしている「顧客志向」という価値観と、AIによって実装のスピードが上がった「AIネイティブ」な開発とが組み合わさることで、お客様への価値提供を最大化できるようになった。これは楽楽自動応対チームに限った話ではなく、AIプロダクト開発に取り組むすべてのエンジニアにとって参考になる視点ではないかと感じています。 rakus.connpass.com 「RAKUS AI Conference 2026 Summer」の他レポート記事 ・ AIを載せることはゴールではない。ラクスCTOと開発副本部長が語った、組織とプロダクトの変革 ・ 楽楽精算AIエージェントを支える、LLMOpsとインフラの選択肢 ・ 仕様駆動開発、導入半年。「本当に速くなってるの?」にデータで答える

2026年7月15日、ラクスは自社イベント「RAKUS AI Conference 2026 Summer」を開催しました。オープニングは、CTO 兼 開発本部長の「公手 真之」と、執行役員 兼 開発本部 副本部長の「矢成 行雄」による2つのセッションです。 一方は「AIネイティブな開発組織をどう作るか」という組織の話。もう一方は「複数のプロダクトにAIをどう実装するか」というプロダクトの話。扱う対象は違いますが、2人が最後に置いた結論は同じでした。AIを載せること自体はゴールではない、というものです。 「SaaS is dead?」にどう答えるか 組織の話：ツールを導入すれば、AI駆動開発は進むのか 「導入すれば自然に進む」という前提 現場の好感触と、伸びない実数 サーベイで「現在地」を可視化する 浸透を止めていた要因と、「強制力」への転換 セッションの結論 プロダクトの話：ユーザーは「正答率」を求めているのか 複数プロダクトで顧客業務を支える 3つのプロダクトの実装例 「正答率」：ユーザーが本当に求めていたもの 「縦の壁」と「横の壁」、そして専門組織 現在地 2つのセッションが指していた同じ方向 おわりに 「SaaS is dead?」にどう答えるか 2人とも、話の入り口はクラウドサービス業界の現状に置いていました。 競合がひしめくレッドオーシャンで、新規の「白地」と他社からの乗り換えを奪い合う。そんな状況を背景に、近年は「SaaS is dead?（クラウドサービスはもう役割を終えるのではないか）」という論調も出てきています。 これに対する2人の答えは、「dead?」ではなく「 SaaS is evolving 」でした。クラウドサービスは終わらず、むしろ進化する。AIはクラウドを置き換えるものではなく、これまで届けてきた価値をもう一段引き上げるものだ、という立場です。 矢成はここに補足を加えました。ラクスはすでに、System of Record に蓄積した信頼できるデータと、それを動かす業務ワークフローを持っている。その土台の上にAIが乗るからこそ価値が出る。「データ・ワークフロー・AI」がそろってはじめて意味を持つ、という整理です。そして「価値そのものだけでなく、それを届けるスピードが競争力になる」という現状認識は、2人に共通していました。 同じ現状認識から出発しながら、公手は「組織をどう変えるか」を、矢成は「プロダクトに何をどう実装するか」を語りました。 組織の話：ツールを導入すれば、AI駆動開発は進むのか 公手のセッションは「複数プロダクト組織のAIネイティブ化における戦略」。冒頭で「ここから先は、少し泥くさい話になります」と断ったとおり、成功事例の紹介ではなく、うまくいかなかった過程の共有でした。 「導入すれば自然に進む」という前提 ラクスは生成AIを早い段階から取り入れてきました。2022年秋には GitHub Copilot を使い始めるメンバーが現れ、2023年4月に全面導入。その後も Cursor、Devin、Claude Code を、現場の判断で比較的自由に導入しています。ツールが先行したぶん、ガイドラインやセキュリティ対策も早めに整えられました。 開発組織は国内が約350人、海外が約100人。各チームは技術スタックも開発拠点も異なり、それぞれが顧客志向のもとで最適なやり方を選び、成果を出してきました。その実績があったからこそ、「優秀な現場にAIツールを渡せば、良い使い方を見つけてAI駆動開発は自然に進むだろう」という前提が置かれていた、と公手は振り返ります。 結果は、その前提どおりにはなりませんでした。 現場の好感触と、伸びない実数 導入後、現場からはインパクトのある報告が上がってきました。あるプロジェクトではコードの95%を生成AIが実装。SPEC駆動開発（SDD）で開発工数を50%削減、E2Eテスト自動化でテスト工数を30%削減、調査コストを25%削減、海外チームとのリードタイムも30%削減。体感面でも「実装が楽になった」「PoCや新機能開発は確実に速くなった」「学習が速くなった」といった声が目立ちました。 一方で、同じ現場から別の声も上がっています。「AIならではの手戻りが発生する」「レビューが重く、品質確認の負荷はむしろ増えた」。ビジネス側からは「開発が明らかに速くなった」という実感が返ってこず、エンジニアに聞いてもリリースが速くなった手応えは曖昧でした。 そこで公手たちは、体感ではなく実数を確認します。全面導入の前後で、リリース回数と新機能の数がどう変化したかを計測したところ、期待したほどには伸びていませんでした（なお公手は、この数値について「機能の規模は無視した参考値」と限界を明示していました）。 ここから導かれた学びは明快です。実装フェーズは確かに楽になった。しかし、その前後の工程やプロセス全体が変わらなければ、価値提供のスピードは上がらない。従来のプロセスにAIツールを足すだけでは、成果には届かないということです。 サーベイで「現在地」を可視化する 次の打ち手は、現状の可視化でした。ラクスには開発者体験の向上をミッションに掲げる技術チームがあり、そのチームが「AI駆動開発がどこまで浸透しているか」を測るサーベイを作成します。開発チームごと・開発工程ごとに、世の中の最新のAI活用事例をベンチマークとして自己評価し、成熟度をスコアリングする仕組みです。 結果として、チーム間のばらつきの大きさが見えてきました。実装フェーズのAI活用は進む一方で、テストやレビューはほぼ手つかず。そして、開発速度が改善しているチームほど、実装以外の工程でもAIを使い、SPEC駆動開発を取り入れている、という相関が確認できました。 浸透を止めていた要因と、「強制力」への転換 ヒアリングからは、浸透を止めている共通の要因が見えてきます。 コスト意識が高いため、効果が見えるまで新しいツールの導入判断に時間がかかる AI活用の「目指す姿」が見えにくく、学習コストを踏まえると日々の開発が優先される チームをリードする推進役が不足し、良い使い方がチーム全体に広がらない これを受けて、公手たちは方針を大きく変えます。これまでのラクスは「各チームの自律的な最適化」で成果を出してきましたが、それに任せるだけでは組織全体としては思うように浸透しない。そこで今期は、組織として明確な方向性を示し、強制力を持って進める方針に踏み込みました。上記の各要因には、それぞれ次の打ち手が当てられています。 各チームごとの効果検証を待たない： 生産性向上がはっきりしていた Claude Code を全面導入し、それを前提とした SPEC駆動開発を、ベトナムやインドネシアの開発拠点も含めて全面展開する 「AI駆動開発 実践カタログ」を整備する： AIネイティブ開発で実践すべき約20項目を職種ごとに定義し、「どこまでやれば実践できていると言えるか」まで明文化する。ガイドラインにとどめず「組織として目指す姿」の共通言語とし、開発マネージャーの目標にも組み込む 推進役を置き、外から支援する： 勉強会や情報共有会、社内イベント、社内報・社内ラジオでの紹介、表彰制度、他チームの有識者による Enabling を用意し、成功事例とノウハウが横に流れる環境を整える 「各チームの自律に任せる」文化を大切にしてきた組織が、あえて「強制力」に舵を切る。公手は、その難しさも含めて率直に語っていました。 セッションの結論 締めくくりで、公手はこう述べました。AIネイティブ開発組織への変革のゴールは、AI駆動開発を浸透させること自体ではない。顧客価値と事業価値を、これまで以上のスピードと品質で生み出すことだ、と。AIの登場から約4年、ラクスの本格的なAIネイティブな開発づくりは動き出したばかりで、「正解はまだ見えにくいが、試行錯誤しながら一歩ずつ進んでいく」と結びました。 プロダクトの話：ユーザーは「正答率」を求めているのか 続く矢成のセッションは「複数プロダクトで進めるAI機能実装 実践から得たリアルな学びとロードマップ実現への挑戦」。組織の話をプロダクトの現場に引き継ぐ内容で、こちらも「うまくいった話」より「ぶつかった話」が中心でした。 矢成はセッションを貫く問いを立てます。AIがコモディティ化する時代に勝負を分けるものは何か。ユーザーは本当に「正答率」を求めているのか。複数プロダクトの同時並行開発の成否は、何によって分かれたのか。 複数プロダクトで顧客業務を支える ラクスの特徴は、単一プロダクトではなく、顧客業務を支える複数のプロダクトを持っていることです。受注・見積・契約といった販売管理、経費精算や仕訳、問い合わせ応対やFAQといったカスタマーサポート。これらが組み合わさることで、販売から経費、サポートまで、顧客の業務がひとつながりで支えられます。矢成はこれを、点ではなく「面で支える」と表現しました。 そこでラクスが選んだのは、複数のプロダクトへ同時並行でAIを実装する道です。一つに絞って局所最適する方法は取りませんでした。矢成が繰り返し強調したのは、「顧客提供価値の向上につながらないAI実装に意味はない」という前提です。流行っているから載せる、載せること自体が目的になる。それを避けることが出発点でした。 3つのプロダクトの実装例 具体例として、3つのプロダクトが紹介されました。 経費精算（楽楽精算）／伝票作成AIエージェント 伝票入力の手間に対して、AI-OCRとエージェントを組み合わせる。領収書をアップロードすると、過去の申請事例などから経費精算データを予測し、入力まで済ませる。手作業が「確認するだけ」に変わる 販売管理（楽楽販売）／DB構成提案 初期設定や業務フロー構築が企業ごとに複雑で、導入のハードルになっていた。そこへ対話型ナビゲーションのAIアシストを導入する。AIと対話しながら進めるだけで自社に合った設定が提案され、専門知識がなくても使い始められる カスタマーサポート（楽楽自動応対）／メール作成エージェント 担当者ごとの応対品質のばらつきに対して、応対履歴や社内ナレッジベースから回答文案を自動生成し、品質を底上げする。さらに応対履歴からFAQ記事を提案・公開し、問い合わせの発生そのものを減らす 技術の実装方法は異なりますが、狙いは共通しています。「ユーザーの手作業」と「専門性の壁」をAIが肩代わりし、顧客が本質的な業務に集中できる状態をつくる。AIの実装は、そのための手段という位置づけです。 「正答率」：ユーザーが本当に求めていたもの 当初、開発チームがもっとも力を入れていたのは正答率の向上でした。エンジニアとしては自然な発想です。しかし、ユーザーの関心はそこにありませんでした。 ユーザーが重視していたのは、正答率そのものよりも「最終的な正解へ、早く楽にたどり着けるか」でした。なぜその答えになったのかの分かりやすさ、方向を示して軌道修正できること、間違ったときにリカバリーしやすいこと。正答率は入り口の一指標にすぎなかったわけです。 打ち手は、人が最後に主導権を持つ Human-in-the-loop の徹底でした。面倒な作業は自動化し、確認と修正は人に残す。「AIが提案し、人が確認する」という役割分担で、精度と安心感を両立させます。矢成はこの優先順位を、次のように言い切りました。 「90%正解でも、確認・修正しづらいAI　＜　80%正解でも、確認・修正しやすいAI」 数字の高さよりも、使う人の体験を優先する。開発に熱が入るほど見落としやすい観点です。 「縦の壁」と「横の壁」、そして専門組織 複数プロダクトを同時に走らせたことで、組織面の課題も見えてきました。矢成はこれを「縦の壁」と「横の壁」と呼びます。 縦の壁（チーム内）： AI機能の開発には、LLMやAIの専門スキルと、業務ドメインの深い理解の両方が必要になる。しかし、すべてのプロダクトチームに両方を求めるのは現実的でない。 横の壁（チーム間）： 複数プロダクトが同時に走ったため、APIのレート制御、LLMの精度評価、トークン消費コストの可視化、負荷試験の設計など、一度作れば共有できるものを各チームが個別に作ってしまう。「車輪の再発明」が各所で発生した。 打ち手は、AI開発の専門組織を新設し、そこに2つの役割を持たせることでした。一つは、難易度の高いコア開発をまとめて引き受ける役割。これにより縦の壁が下がり、各プロダクトチームは自分たちが最も詳しいドメインの実装に集中できます。もう一つは、ガイドライン策定や定例でのナレッジ共有など、知識の標準化を横に広げる役割。これにより横の壁が下がります。この設計は、専門性の高い開発を集約するチームと横展開を支援するチームを分ける「チームトポロジー」の考え方を下敷きにしたもので、この組織はAIロードマップを継続的に実現する役割も担い始めています。 現在地 現時点では、複数のプロダクトにAIが載り、個々の業務効率化で成果が出はじめた段階です。業務ルールや運用にAIが寄り添う「協働型AI」の一部が実現しています。この先は、プロダクト個別の最適化から、データとワークフローをプロダクト横断でつなぐ段階へ。さらに、より大きな顧客価値を生む相乗効果へと進め、プロダクトをより「AI Native」「Agentic」に近づけていく、そう結ばれました。 2つのセッションが指していた同じ方向 組織の話とプロダクトの話は、結論が重なりました。 公手：変革のゴールはAI駆動開発の浸透ではなく、顧客価値と事業価値をこれまで以上のスピードと品質で生み出すこと 矢成：AIを載せること自体が目的ではなく、顧客が本質的な業務に集中できる体験をつくり続けること どちらも主語は顧客です。AIは、価値提供のスピードと品質を上げるための手段として位置づけられている。 ラクスが創業から重視してきた「顧客志向」が、AIという新しい道具を得ても一貫している。 これが2つのセッションに共通するメッセージでした。矢成が立てた「勝負を分けるものは何か」という問いの答えも、モデルの性能や正答率ではなく、AIを顧客の体験にどこまで着地させられるか、という一点にあると読み取れます。 この2つは、「複数プロダクトを持つ組織である」という前提でもつながっています。各領域で最良の製品をそろえる「ベストオブブリード」は、ラクスが長年強みにしてきたものです。矢成の話はこの強みをAI時代に生かす戦略であり、公手の話はその複数プロダクトを横断してAIネイティブ化を進める土台づくりにあたります。開発本部が掲げる「顧客に価値を高速提供できるAIネイティブな開発組織へ変革し、次世代の統合型ベストオブブリードを実現する」というビジョンを、組織とプロダクトの両面から具体化しようとしている、と位置づけられます。 両者が共通して触れていたのが、これから強化したい人材像でした。公手が挙げたのは2種類のエンジニアです。AIが高品質な成果を出し続けられる開発基盤（ハーネス）を設計できるエンジニアと、「何を作るか」を研ぎ澄ます顧客価値の設計エンジニア。実装のボトルネックが解消された先で問われるのは「何を作るか」であり、この視点は矢成の言う「業務ドメインの深い理解」とも重なります。 おわりに 今回の2セッションは、「AIでこれだけ成果が出た」という事例集ではありませんでした。「ツールを導入しても進まなかった」「正答率を上げても使われなかった」と、うまくいかなかった過程を共有する内容です。AIをどう組織に根づかせ、どうプロダクトの価値に変えるか。同じ課題に直面している開発組織は少なくないはずで、ラクスもまた、正解の見えにくい中を試行錯誤しながら進んでいる最中です。 そして、ここで語られた変革は、まだ道半ばです。強制力を持って浸透を進める組織づくりも、顧客体験に着地させるプロダクトづくりも、これから担い手を必要としています。ラクスの開発本部では、先に触れた2つの人材像を、まさに募集しています。この試行錯誤を一緒に進めてくれる方は、ぜひ一度 採用ページ をのぞいてみてください。 また、当日の発表資料はSpeakerDeckで公開しています。ぜひあわせてご覧ください。 - 発表資料 speakerdeck.com speakerdeck.com なお、8月下旬ごろに発表のアーカイブ動画をラクスエンジニア情報ポータルサイトにて公開予定です。 - ラクスエンジニア情報ポータルサイト https://career-recruit.rakus.co.jp/career_engineer/ 「RAKUS AI Conference 2026 Summer」の他レポート記事 ・ 顧客の声から生まれた『AI返信補助機能』の開発プロセス ・ 楽楽精算AIエージェントを支える、LLMOpsとインフラの選択肢 ・ 仕様駆動開発、導入半年。「本当に速くなってるの?」にデータで答える

こんにちは、菊池（akikuchi_rks）です。 私の所属するチームではClaude Codeを開発フローに取り入れており、私自身も設計書のレビューや定型調査の自動化など、さまざまな業務でスキル（Agent Skills）を作成してきました。 スキルを書き続けていて特に感じるのは、「とりあえず動くスキル」と「安定して業務に組み込めるスキル」は別物だということです。同じスキルなのに実行のたびに結果の形が変わる、自分は使えるのにチームメンバーが動かすと品質が落ちる、という悩みに心当たりのある方も多いのではないでしょうか。 私はこの差を分けるのは、 AIにどう仕事を任せるかをしっかり設計できているかどうか だと思っています。Anthropicもスキルを作ることを 「新しく入社したメンバー向けのオンボーディングガイドを用意すること」に例えています 。新しいメンバーに仕事を任せるときと同じように、スキル設計でも、依頼内容を明確にし、任せる範囲と体制を決め、成果物の品質を確認し、実行結果を見て次の任せ方を調整する必要があります。 依頼内容を明確にする 誰に、どの単位で任せるかを決める 品質確認の仕組みを組み込む 仕事ぶりを評価して、次の任せ方に活かす 上記の4つをおさえていると、同じスキルを誰がいつ動かしても、期待した品質のアウトプットが安定して返りやすくなります。 本記事ではこの4つのポイントについて紹介していきたいと思います。 ポイント1：依頼内容を明確にする ポイント2：誰に、どの単位で任せるかを決める (a) スクリプトに切り出すか (b) 並列化（サブエージェント分業）するか (c) コンテキストの分割単位 (d) どのモデルを使うか ポイント3：品質確認の仕組みを組み込む ポイント4：仕事ぶりを評価して、次の任せ方に活かす (a) 評価指標を決める (b) 評価スキルを作る (c) 改善の意思決定は人間に残す 見つけた失敗をGotchasとしてスキルに反映する まとめ ポイント1：依頼内容を明確にする スキル設計で最初にやるべきことは、期待するアウトプットを定義し、それを生成するために必要なインプットを逆算することです。 アウトプットの定義では、フォーマット、粒度、含めるべき要素、含めてはいけない要素を具体化します。「レビュー結果を出す」ではなく、「指摘はMUST／SHOULD／IMO／FYI／nitsの5段階で分類し、MUSTとSHOULDには観点種別と修正例を必ず添える。」というレベルまで落とし込みます。 アウトプットだけでなく、AIが判断してよい範囲も明確にします。「要件に沿って修正案を作る」ことは任せても、「どの修正を採用するか」「本番環境へ反映するか」といった意思決定は人間が行う、というように責任の境界を決めておくことが重要です。 インプットの定義では、そのアウトプットをAIが生成するために必要な情報をすべて列挙します。 業務知識やドメイン用語の補足 参照すべき既存ドキュメントやコード 過去事例と反例 守るべき制約やルール ここを曖昧にしたままプロンプトを書き始めると、「動くが品質が安定しない」スキルになってしまいます。過不足の点検には「人間に同じ仕事を頼むなら何を渡すか？」という問いが有効です。Anthropicの プロンプトベストプラクティス も、Claudeを「優秀だが、あなたの組織の規範や仕事の流れをまだ知らない新しい社員」と考えるよう勧めています。 インプットが足りていないと、AIは不足した情報を推測で補完し始めます。一方で、実行ごとにアウトプットの構造や粒度が変わる場合は、アウトプットの定義が曖昧な可能性があります。どちらの場合も、プロンプトの表現を調整する前に、インプットやアウトプットの定義に戻って見直すことをおすすめします。 ポイント2：誰に、どの単位で任せるかを決める インプット・アウトプットの定義が固まったら、次はその情報量を見積もります。コンテキストウィンドウは有限であり、手当たり次第に全部詰め込むと精度が落ちるためです。人に例えるなら、1人に資料を全部抱えさせるのか、チームを組んで分担させるのか、そもそも機械的にツールで処理すべきかを決める工程です。判断軸は4つあります。 (a) スクリプトに切り出すか 日付計算、ファイルの存在チェック、フォーマット変換のような決定的に実行できる処理は、AIに自然言語で解釈させるのではなく、スクリプトに切り出します。曖昧さの入り込む余地がなくなるぶん、結果が安定します。人に任せる仕事と、ツールで済ませる仕事を分けるのと同じ判断で、AIエージェントに任せる範囲を決める前に、そもそも決定的な処理として切り出せないかを検討すると、後段の設計がシンプルになります。 (b) 並列化（サブエージェント分業）するか 情報量が多い場合や、独立したサブタスクが複数ある場合は、サブエージェントに分業させます。例えば「複数ファイルの調査 → 統合レポート」のようなタスクであれば、調査をサブエージェントに並列で投げ、統合判断は親エージェントが担当する構成にします。 分業で気をつけたいのは、任せた相手に依頼が正しく伝わっているかどうかです。Anthropicは How we built our multi-agent research system のブログ記事において、サブエージェントへの委譲プロンプトに「目的」「出力形式」「使用するツールと情報源の指針」「タスクの境界」の4要素を含めることを挙げています。「いい感じに調査しておいて」という丸投げが事故のもとになるのは、人間相手でもサブエージェント相手でも変わりません。 また、サブエージェントは毎回まっさらなコンテキストで起動するため、親セッションで既に読み込んだスキルを引き継ぎません。スキルを前提にした作業を確実に任せたい場合は、サブエージェント定義の skills フィールドでスキルを事前ロードするか、委譲するプロンプトにスキルの使用を明示しておく必要があります。 (c) コンテキストの分割単位 1回の呼び出しに入るインプットサイズを試算し、入らない・精度が落ちるようであれば、意味のある単位で分割します。このとき、分割の境界を「サブエージェントの責任範囲」と一致させると設計がきれいになります。逆にここがズレていると、サブエージェント間で情報を受け渡すための余計な仕組みが必要になりがちです。 例えば50ページの設計書なら、1ページ4,000文字として約20万文字です。日本語1文字あたりのトークン数は使用するモデルのトークナイザによって変わるため、正確な数値は OpenAI Tokenizer などで実測するのが確実ですが、経験的には0.5〜1トークン程度に収まることが多いです。この例では10万〜20万トークン相当となり、200Kのコンテキストウィンドウの大半を占める規模になります。ウィンドウにはスキル本文や参照コード、出力の分も載るうえ、インプットが大きいほど読み落としも増えるため、1サブエージェントに渡すインプットは数万トークン程度に収めたいところです。この例なら10ページ（2万〜4万トークン）が目安で、50ページ÷10ページで、およそ5分割が必要という見積もりが立ちます。 そのうえで、実際の分割の境界は「10ページずつ」と機械的に切るのではなく、「機能ごと」に切ります。ページ数で切ると1つの機能の説明が複数のサブエージェントにまたがるため、担当範囲だけでは整合性を判断できず、互いのレビュー結果を突き合わせる仕組みが別途必要になってしまいます。機能ごとに切れば、各サブエージェントは自分の担当範囲だけでレビューを完結でき、親エージェントは結果を束ねるだけで済みます。 (d) どのモデルを使うか タスクの複雑さで選びます。 機械的な抽出や整形 → 軽量モデル（Haikuなど） 通常の設計や実装 → 標準モデル（Sonnetなど） 複雑な判断、横断的な統合 → 高性能モデル（Opusなど） サブエージェント側を軽量モデル、親を高性能モデルにする構成は、品質とコストのバランスが良く、私もよく使っています。ただし、使い分けは思い込みで固定せず、実際に複数モデルで試して決めるのが確実です。軽量モデルで十分だと思っていたタスクが実は足りなかったり、その逆だったりということはよくあります。 ポイント3：品質確認の仕組みを組み込む 一発生成では、どうしても品質にばらつきが生まれます。そのため、生成した成果物を確認し、必要に応じて修正する仕組みをスキルの中に組み込むことが重要です。人に仕事を任せるときも、成果物の品質確認をせずそのまま使うことは少ないはずです。 レビューのさせ方には2種類あります。 セルフレビュー : 同じエージェントに続けてレビューを指示する方法 クロスレビュー : 別のサブエージェント（別視点、別ペルソナ）にレビューさせる方法 セルフレビューは構成がシンプルでコストも低く済みます。一方で、生成時と同じ文脈や思考を引き継ぐため、見落としを見つけにくい場合があります。品質を重視するタスクでは、別のエージェントにレビューさせるクロスレビューの方が、多様な視点から確認できるため有効なケースが多いと感じています。AIエージェントの設計パターンを整理した Agent Design Pattern Catalogue でも、生成結果を自分自身で振り返る Self-reflection と、別のエージェントやモデルがレビューを行う Cross-reflection が代表的なリフレクションパターンとして紹介されています。品質要件やコストに応じて、両者を使い分けることが重要です。 クロスレビューでは、レビュー担当のサブエージェントに明確なペルソナを割り当てることで、視点の重複を防ぎつつ観点の網羅性を高められます。例えば私のチームで運用している並列レビュースキルでは、次のようにレビュー担当を分けて並列に走らせています。 チェックリスト検証担当 : プロジェクトのレビューチェックリストと変更内容を項目単位で突き合わせる 実装検証担当 : レイヤー構成、NULL安全性、コーディング規約に絞ってコードを見る テスト観点検証担当 : テストの網羅性、命名規則、ユビキタス言語の使用を検証 既存コードとの一貫性検証担当 : 既存の実装パターン・命名との整合性を確認 不具合検出担当 : diff内の情報のみから明らかなバグを検出 委譲プロンプトでは、各サブエージェントに対して「役割（何を検証するか）」「参照するガイドライン（事前に読み込むスキル）」「タスクの手順」を明示します。ペルソナと担当範囲を絞るほど、それぞれのレビューが深く掘り下げられます。逆に「気になる点を挙げて」と丸投げすると、複数のペルソナが同じ論点を重複して指摘したり、無難な指摘に流れたりしがちです。 ポイント4：仕事ぶりを評価して、次の任せ方に活かす スキルが増えてくると、「このスキルは本当に良いのか」「どこまで任せて大丈夫なのか」を判断する基準が必要になります。人に仕事を任せるときも、仕事ぶりを見て任せる範囲を広げたり、フォローを厚くしたりするはずです。最終的に目指したいのは、スキル自体を継続的に改善できる仕組みです。 私が実際に運用している改善ループの全体像は次のとおりです。 改善ループ このループを回すために押さえるべきなのは、(a)評価指標を決める、(b)評価スキルを作る、(c)改善の意思決定は人間に残す、の3つです。以下で順に紹介します。 (a) 評価指標を決める スキルごとに、品質を測る評価指標を定義します。 設計書生成スキルなら「観点の網羅率」「業務制約への準拠率」「再実行時のブレ幅」 レビュー系スキルなら「指摘の真陽性率」「重大度判定の妥当性」 指標がないと「なんとなく良くなった気がする」で改善が止まってしまいます。Anthropicの 公式ベストプラクティス も、スキルの中身を書き込む前にまず評価を作ること（evaluation-driven development）を推奨しています。この推奨を実践している例が skill-creator で、スキルを書く前に評価ケースを用意し、スキルあり・なし（または改善前・改善後）の結果を比較しながら改善を進める作りになっています。 (b) 評価スキルを作る 決めた指標を機械的に評価するための 評価スキル を別途用意します。インプットは対象スキルのアウトプット、アウトプットは指標ごとのスコアと改善提案です。 評価スキルは人間によるレビューの代替ではなく、人間がレビューする前のスクリーニングとして機能させるのが現実的だと思います。 (c) 改善の意思決定は人間に残す 評価スキルの結果を起点に、スキル自体をブラッシュアップするループを回します。ここで私が守っているのは、改善案を複数出させて、 人間が選ぶ ことです。AIに全自動でスキルを書き換えさせると、改善の方向性が本来の目的からずれていきやすくなります。意思決定だけは人間に残すのが、遠回りに見えて結果的に速いというのが私の経験則です。 評価指標を決め、評価を継続的に行い、その結果を人間が判断して改善につなげる。この一連の流れを仕組みとして持つことで、スキルは一度作って終わりではなく、継続的にブラッシュアップできるようになります。 見つけた失敗をGotchasとしてスキルに反映する 上記のような改善ループや日々の運用で見つけた失敗パターンは、スキルの注意書き（Gotchas、落とし穴）として蓄積していきます。人に仕事を引き継ぐとき、「この処理はここで転びやすい」と注意事項を添えるのと同じです。Claude Codeの開発チームも、 スキルの中で最もシグナルが高いのはGotchasセクションだ と述べています。 最初から完璧な指示を書くのは難しいので、運用しながら失敗を吸収してスキルを厚くしていく方が現実的です。上述の評価ループで見つかった失敗はもちろん、日常運用で気づいた注意点も、その都度スキルに追記していきます。 まとめ スキルを書くことを「AIへの仕事の任せ方の設計」と捉え直して、4つのポイントを紹介しました。 依頼内容を明確にする（アウトプットとインプットの定義） 誰に、どの単位で任せるかを決める（スクリプト化、並列化、分割、モデル） 品質確認の仕組みを組み込む（セルフレビューとクロスレビュー） 仕事ぶりを評価して、次の任せ方に活かす（評価指標、改善ループ、Gotchas蓄積） どれも特別なテクニックではなく、人に仕事を任せるときにも自然に行っていることです。AIを「仕事を任せる相手」と捉えて設計するだけで、スキルの再現性や改善のしやすさは大きく変わると感じています。 そして、その効果は業務効率化にとどまりません。AIに安心して任せられる仕事が増えるほど、私たちは顧客の本質的な課題解決のための対話や、高度な機能開発といった、人間にしかできない価値創造の仕事に集中できるようになります。 私自身もまだ試行錯誤の途中ですが、本記事で紹介した考え方が、スキル設計を見直すきっかけになれば嬉しいです。 なお、本記事で扱わなかったSKILL.mdそのものの書き方（descriptionの設計、ファイル構成、progressive disclosureなど）については、 Anthropic公式のベストプラクティス にまとまっているので、そちらをご覧ください。

こんにちは、技術広報の yayawowo です。 私たち株式会社ラクス開発本部では、Missionである 「顧客の成長を支援する、圧倒的に使いやすいクラウドサービスを創り提供する」 を念頭に、日々プロダクト開発に励んでいます。 現在、ラクスでは歴史あるロングセラーのプロダクトから、近年立ち上がった新規プロダクトまで、多くの開発プロジェクトが並行して動いています。このように古いものから新しいものまで多くのプロダクト開発に深く携われるからこそ、エンジニアやデザイナーが触れられる技術の機会が非常に多い点が、私たちの組織の大きな特徴であり魅力です。 本記事では、各プロダクトの「技術スタック」を改めて整理し、皆様に最新情報をお届けしたいと思います！自社開発に携わるエンジニア、デザイナーだけでなく、これから携わりたい！という方にも必見の内容です。 現場のリアルな最新データから見えてきたのは、単なるツールの変更履歴ではありません。 ラクスが開発組織として一貫して掲げている「技術選定の思想」そのものでした。 各組織の最新スタックを公開する前に、まずは私たちが大切にしている「2つのコア思想」を技術広報の視点からご紹介します！ 1. ラクスが技術選定で掲げる「2つのコア思想」 ① お客様の日常を守り、進化させるための「顧客志向」 ② 技術を「価値創造」に集中させるための「AIネイティブ＆自動化」 2. 各プロダクトの紹介 ＆ 最新技術スタック 楽楽精算 楽楽明細 楽楽電子保存 楽楽債権管理 楽楽勤怠（給与計算） 楽楽販売 楽楽請求 楽楽自動応対開発 楽楽メールマーケティング blastmail / blastengine 3. それを支える連携部署の技術スタック フロントエンド推進課 SRE AI開発課 ＆ AIエージェント開発課 QA課 インフラ開発部 プロダクトデザイナー 4. 終わりに 1. ラクスが技術選定で掲げる「2つのコア思想」 今回、全社規模で集まった最新のデータを見て、技術広報である私が一番強く感じたのは、ラクスが大切にしている「技術選定のブレない軸」でした。私たちは、単に流行りのツールを追いかけるのではなく、以下の2つの思想をベースに日々の開発環境をアップデートしています。 ① お客様の日常を守り、進化させるための「顧客志向」 ラクスにとって、技術は「自分たちが使いたいから」選ぶものではありません。すべては「お客様の業務をいかに楽にできるか」という目の前の課題を解決するための最高の手段です。 私たちのクラウドサービスは、ありがたいことに数万社を超えるお客様の日常のビジネスを支える社会インフラになっています。だからこそ、長年培った圧倒的な安定基盤を深くリスペクトし、1分1秒のダウンも許されない堅牢性を守り抜く責任があります。しかし、私たちは「守り」だけでは終わりません。お客様へより速く、より安全に新しい価値を届けるために、歴史のあるプロダクトほど「お客様の未来のために、今最適な武器は何か」を貪欲に追求し、裏側では大胆なモダナイズを仕掛けています。 ② 技術を「価値創造」に集中させるための「AIネイティブ＆自動化」 お客様の課題解決に1分1秒でも多くの時間を割くため、ラクスはエンジニアの創造性を奪う泥臭い手作業や無駄な作業を徹底的に排除する環境作りに本気で取り組んでいます。 今回、一際目を引いたのが、各現場の「AIと自動化へのリアルな使い分け」です。単に世間の流行りに乗って同じツールを一律で入れるのではなく、プロダクトの特性に合わせて最適な技術スタックを現場主導で選定しています。そして何より特徴的なのが、ほぼすべての組織が、実装前の「壁打ち相手」としてAIをフル活用している点です。単にツールを入れて楽をするためではなく、エンジニアが本来向き合うべき「顧客のための価値ある設計や、より良いユーザー体験の創造（本質）」に100%集中できる環境を、ラクスは本気で作り上げています。 具体的にどんなツールを、どんな考え方で使い分けているのか？ それは、この後各プロダクトの技術スタックにてご紹介します。 2. 各プロダクトの紹介 ＆ 最新技術スタック ここからは、ラクスが展開する各クラウドサービスと、現場のエンジニアが2026年度現在、実際に選定して使っている技術スタックをご紹介します。 楽楽精算 会社の「経費精算」にかかる時間と労力を劇的に減らすシステムです。利用者はスマホで領収書を撮影するだけで金額や日付が自動入力され、面倒な紙の提出や手入力をすることなく精算を完了できます。経理担当者にとっても、確認や承認の負担を大幅に削減する「日本のバックオフィスを楽にする」代名詞的な存在です。 ✅バックエンド カテゴリ 技術スタック 使用言語 Java、Swift、Kotlin MW PostgreSQL、Postfix、Apache、Room、Realm FW・ライブラリ Spring Boot、jQuery、Retrofit2 開発ツール IntelliJ IDEA、Xcode、Android Studio、Flyway、Redmine、GitHub、VSCode CI・テスト Selenide、Gradle、JUnit、JMeter、Jenkins、GitHub Actions AI Claude Code、Codex、GitHub Copilot、Gemini、ChatGPT、Notebook LM、Cursor ※2026年7月時点での情報です。 ✅フロントエンド カテゴリ 技術スタック 使用言語 HTML、CSS、JavaScript、TypeScript FW・ライブラリ React、jQuery、MUI、Jotai、zod、TanStack Form、Tanstack Query、Sass、Vite、ESLint、Prettier、Biome、Storybook、msw 開発ツール GitHub、GitHub Projects、VSCode、OpenAPI、Figma CI・テスト GitHub Actions、Jenkins、Playwright、Vitest AI Claude Code、Codex、GitHub Copilot、Gemini、ChatGPT、Notebook LM ※2026年7月時点での情報です。 楽楽明細 企業が取引先に発行する「請求書」や「納品書」を、すべてWeb上で一括配信するシステムです。これまでは担当者が印刷し、封筒に詰め、切手を貼って郵送していた手作業をゼロにします。受け取る側の取引先もマイページからいつでも即座に確認・ダウンロードできるため、双方のペーパーレス化と業務スピードアップを同時に実現しています。 カテゴリ 技術スタック 使用言語 Java、TypeScript、JavaScript MW PostgreSQL、Tomcat、Postfix、Docker、Redis、AWS Lambda / EventBridge / Step Functions / S3 / SQS FW・ライブラリ SpringBoot、React、Redux、JasperReports、Lombok、Jooq、jQuery、GraphQL 開発ツール IntelliJ IDEA、VSCode、Redmine、GitHub、gulp.js、webpack、Storybook CI・テスト Gradle、jUnit、Playwright、GitHub Actions AI Claude、Claude Code、GitHub Copilot、ChatGPT、Codex、Notebook LM、Gemini ※2026年7月時点での情報です。 楽楽電子保存 国税関係の書類（領収書や請求書など）を、国が定める「電子帳簿保存法」の厳しい要件に100%準拠して、安全にクラウド保存・一元管理できるシステムです。ユーザーは「法律が変わってどう対応すればいいかわからない…」という不安から解放され、検索機能を使っていつでも過去の書類を1秒で見つけ出せるようになります。 カテゴリ 技術スタック 使用言語 Java、TypeScript、JavaScript MW PostgreSQL、Nginx、Tomcat、Postfix、Docker、Kubernetes、Node.js、AWS Lambda / S3 / DynamoDB / API Gateway / SQS FW・ライブラリ React、MUI、MSW、Spring Boot、Jooq 開発ツール IntelliJ IDEA、GitHub、Vite、VSCode、Open API、Figma、ESLint、Prettier、Yarn CI・テスト Gradle、JUnit、GitHub Runner、Vitest、Cypress、argoCD、Playwright、GitHub Actions AI Claude、Claude Code、GitHub Copilot、ChatGPT、Codex、Notebook LM、Gemini ※2026年7月時点での情報です。 楽楽債権管理 「取引先からちゃんとお金が振り込まれているか」を確認する、企業の経理で最も神経を使う入金消込・債権管理業務をスムーズにするシステムです。銀行の入金データと自社の請求データを自動で照合し、ミスマッチがあればすぐに通知。人の目によるダブルチェックや残高管理のプレッシャーから担当者を解放し、確実な資金管理を支えます。 カテゴリ 技術スタック 使用言語 Java、TypeScript、JavaScript MW PostgreSQL、Tomcat、Docker、AWS S3 FW・ライブラリ React、MUI、Spring Boot、jOOQ、DuckDB、OpenTelemetry、Spring AI 開発ツール IntelliJ IDEA、VSCode、Redmine、GitHub、Open API、Figma CI・テスト Gradle、jUnit、Playwright、GitHub Actions、Spock、runn AI Claude、Claude Code、GitHub Copilot、ChatGPT、Codex、Notebook LM、Gemini ※2026年7月時点での情報です。 楽楽勤怠（給与計算） 従業員の日々の「出退勤」を正しく記録し、労働時間や時間外労働時間を自動で集計、そのまま給与計算システムへとデータをスムーズに連携させるシステムです。シフト管理や有給休暇の消化状況もひと目でわかるため、中小企業から大企業まで、複雑な労務管理をミスなくシンプルに行える環境を作ります。 カテゴリ 技術スタック 使用言語 PHP、Python、JavaScript、TypeScript MW MySQL、Nginx、Docker、Node.js、Gunicorn FW・ライブラリ Flow、Vue.js、Fast API、Pinia / Pinia Colada, Vue Router, Vue I18n, Vite, Tailwind CSS, ESLint, Prettier, Storybook, msw 開発ツール GitHub、GitHub Projects、PhpStorm、IntelliJ IDEA、VSCode、Cursor、OpenAPI、Figma、renovate CI・テスト GitHub Actions、PHPUnit、PHPStan、Selenium、Ansible AI Claude、Claude Code、GitHub Copilot、ChatGPT、Codex、Notebook LM、Gemini、VertexAI ※2026年7月時点での情報です。 楽楽販売 販売管理、顧客管理、案件管理など、自社のやりたい業務に合わせて画面や項目をノーコードで自由自在に構築できるWebデータベースシステムです。Excelで属人化してしまっていた複雑なデータをチーム全員で見える化し、ボタン一つでの帳票発行や、ルーチンワークの自動化によって、会社全体のコア業務を劇的にスピードアップさせます。 カテゴリ 技術スタック 使用言語 PHP、Java MW PostgreSQL、Postfix、Apache、Redis FW・ライブラリ Zend Framework、jQuery 開発ツール VS Code、Cursor、GitHub CI・テスト Selenium/Selenide、PHPUnit、JMeter、Jenkins、PHPStan、Playwright AI Claude Code、Codex、ChatGPT、Devin、Notebook LM ※2026年7月時点での情報です。 楽楽請求 取引先から紙、PDF、メールなど様々な形でバラバラに届く「受領請求書」を、一つの画面でスマートに一元管理するシステムです。高性能なAI-OCRが中身を自動で読み取ってくれるため、手入力の手間が激減。仕訳データや支払処理、データの保存までをワンストップで効率化し、毎月発生する「請求書処理の山」を瞬時に片付けます。 カテゴリ 技術スタック 使用言語 Java, Kotlin、TypeScript MW PostgreSQL、Pure Storage、Redis、nginx、Tomcat、Kubernetes、AWS[SQS、SES、S3] FW・ライブラリ Spring Boot、jOOQ、React、MUI、Storybook 開発ツール IntelliJ IDEA、Flyway、Gradle、detekt、GitHub、OpenAPI、Figma CI・テスト Playwright、Kotest、Vitest、ArgoCD、Grafana AI GitHub Copilot、ChatGPT、Devin、Notebook LM、Claude ※2026年7月時点での情報です。 楽楽自動応対開発 お客様から届く膨大な問い合わせメールやチャットを、チーム全員で一元管理・共有するシステムです。「誰がどのメールに対応しているか」「返信待ちか、対応済か」がリアルタイムに全員に共有されるため、ネットショップやサポート窓口での対応漏れや、二重返信によるクレームを完全に防ぎ、顧客対応の品質を最大化します。 カテゴリ 技術スタック 使用言語 PHP、Node.js、TypeScript MW PostgreSQL、Apache、Postfix、AWS Lambda / S3 / DynamoDB / SQS、Qdrant FW・ライブラリ Laravel、jQuery、CKEditor、Socket.IO、Vue.js、NestJS 開発ツール PhpStorm、Github、VS Code CI・テスト Selenium/Selenide、PHPUnit、Vitest、Biome、Jenkins、GitHub Actions、Ansible AI Claude Code、Codex、GitHub Copilot、 ChatGPT、 Devin、 Notebook LM ※2026年7月時点での情報です。 楽楽メールマーケティング 企業のマーケティングや営業担当者が、顧客へ一斉にメルマガや案内メールを配信し、そこからの成果を最大化するためのシステムです。ただ送るだけでなく、「誰がメールを開いたか」「どのURLをクリックしたか」を直感的に分析可能。見込み客の興味関心を可視化することで、次の商談獲得へのアプローチをシンプルかつ効果的に支えます。 カテゴリ 技術スタック 使用言語 PHP、TypeScript MW PostgreSQL、Postfix、Nginx、Apache、Redis FW・ライブラリ Slim、jQuery、Vue.js 開発ツール PhpStorm、GitHub、Docker、Podman CI・テスト Playwright、Puppeteer、Jenkins、JMeter、PHPUnit、PHPStan、PHP_CodeSniffer、PHPDoc、Ansible、vegeta AI Claude Code、Codex、GitHub Copilot、ChatGPT、Devin、Notebook LM ※2026年7月時点での情報です。 blastmail / blastengine 「blastmail」は数百万通ものメールを顧客へ一瞬で確実に届ける独自の配信システム、「blastengine」はエンジニアが自社のシステムやアプリに組み込んで、通知メールなどを超高速で自動配信させるためのAPI・リレーサービスです。どちらも「遅延なく、迷惑メールに振り分けられることなく、確実に届ける」という配信技術の極限を支えています。 カテゴリ 技術スタック 使用言語 Java、TypeScript、Go、Python MW Docker、PostgreSQL、MongoDB、Postfix、RabbitMQ、AWS[EC2、ECS、RDS、S3、Lambda、SQS] FW・ライブラリ SpringBoot、React、Quarkus 開発ツール VSCode、GitLab、Redmine、Gradle、OpenAPI、Figma、StoryBook CI・テスト GitLab CI/CD、JUnit、Vitest、Biome、Playwright AI Claude Code、Codex、GitHub Copilot、Gemini、ChatGPT、Notebook LM ※2026年7月時点での情報です。 3. それを支える連携部署の技術スタック ラクスには、各プロダクトの提供価値を最大化し、開発組織全体のエンジニアリング水準を横断的に引き上げる連携・専門組織が存在します。実務で選定している先進的な「武器」をご紹介します。 フロントエンド推進課 フロントエンド推進課は、ラクスの各サービス開発チームと協力し、フロントエンド領域からプロダクトの成長と品質向上を支える専門組織です。 新機能開発や既存機能のUI/UX改善に加え、技術的負債の解消、リアーキテクト、パフォーマンス改善、デザインシステム構築、共通UIコンポーネント開発など、サービス単体では対応しきれない横断的なテーマにも取り組んでいます。 各プロダクトの事業フェーズや技術課題を踏まえ、開発現場に入り込みながら、ユーザーにとって使いやすく、開発者にとって継続的に改善しやすいフロントエンドを実現していくことが役割です。 技術を目的化するのではなく、ユーザー価値、開発生産性、品質、保守性を高めるためにどう活用するかを重視し、プロダクトとチームの両面からラクスのサービス成長に貢献しています。 カテゴリ 技術スタック 使用言語 HTML、CSS、JavaScript、TypeScript FW・ライブラリ React, TypeScript, MUI, RHF, zod, Tanstack Router, Tanstack Query, zustand, emotion, Vue.js, Pinia / Pinia Colada, Vue Router, Vue I18n, Vite, Tailwind CSS, ESLint, Prettier, Storybook, msw 開発ツール GitHub, Github Projects, VSCode, OpenAPI, Figma, renovate CI・テスト GitHub Actions, Playwright, Vitest, happy-dom AI Claude Code, Codex, Copilot, ChatGPT, Gemini, Notebook LM ※2026年7月時点での情報です。 SRE ラクスにおけるSREでは、開発とインフラの知見を活かして顧客への価値提供スピード向上に寄与する自動化・標準化（生産性向上のための取り組み）を推進する役割を担います。 開発とインフラを繋ぐHubというビジョンを持ちながら、システムのモダナイズ化や基盤の構築を行う役割です。 開発言語は主にGoを利用し、横断的なトイル削減や運用の自動化を推進しています。 新しい技術スタック調査などを進めながらノウハウを各サービスへ広めることで、開発部門全体のアーキテクチャ刷新へ寄与していきます。 カテゴリ 技術スタック 使用言語 Go 仮想基盤 Kubernetes MW PostgreSQL, Amazon Aurora, Redis, Kafka FW・ライブラリ gRPC CI/CD・IaC GitHub Actions, ArgoCD, Argo Workflows, Argo Event, Hashicorp Vault, Terraform, Helm 運用・監視 Grafana Stack AI Claude Code, Codex, GitHub Copilot, ChatGPT, Devin, Notebook LM ※2026年7月時点での情報です。 AI開発課 ＆ AIエージェント開発課 ラクスが提供する各プロダクトへ実用的なAI機能を組み込むための研究開発や、社内の複数プロジェクトを横断して業務を自動化する「AIエージェント」の実装・導入を牽引する最先端チームです。 ✅AI開発課 カテゴリ 技術スタック 使用言語 Python MW PostgreSQL、Redis、DynamoDB、Docker、Kubernetes FW・ライブラリ PyTorch、Keras、TensorFlow、FastAPI、OpenAI API、AWS Bedrock、Vertex AI 開発ツール GitHub CI・テスト GitHub Actions、pytest、Terraform AI（開発支援） Claude Code、GitHub Copilot、ChatGPT、Notebook LM、Cursor (OpenSpec) ※2026年7月時点での情報です。 ✅AIエージェント開発課 カテゴリ 技術スタック 使用言語 Java, TypeScript, Python MW amazon corretto, tomcat, postgres, Kubernetes, AWS[Lambda, SQS, SNS, Bedrock, EKS, CloudWatch, DynamoDB, S3, KMS], ArgoCD, Grafana, Litellm, flipt, Otel-collector FW・ライブラリ Spring Boot, Mastra, Hono 開発ツール Gradle, Github, Zed, Visual Studio Code, pnpm, mise CI・テスト junit, vitest, testcontainer, Github Actions AI（開発支援） Claude Code, Codex, Github Copilot Agent, Devin ※2026年7月時点での情報です。 QA課 各プロダクトに準ずる開発環境や仕様を深く理解し、お客様に届くクラウドサービスの品質を「テスト・保証」の側面からハックする品質専門組織です。 カテゴリ 技術スタック 使用言語・MW 各プロダクトに準ずる 開発ツール・FW 各プロダクトに準ずる CI・テスト Playwright、Jenkins 他、各プロダクトに準ずる AI Claude Code、ChatGPT、Gemini、Notebook LM ※2026年7月時点での情報です。 インフラ開発部 8割のサービスリソースをオンプレミスで構築しております。 オンプレミス環境でも自動化などなるべくソフトウェア視点のアプローチが出来るようにHCIで基盤構築し運用効率化をしています。 今後のアップデートとしては、クラウドで先行構築したクラウドネイティブなコンテナ環境やCI/CD環境などをオンプレミス環境にフィードバックし、自動化、自立化を推進しつつもコスト優位性を出せるシステムを構築していきます。 カテゴリ 技術スタック 使用言語 Python、Bash プラットフォーム On-Premise、AWS「EC2、ECS、EKS、RDS、S3、Lambda・・・etc」、GCP ネットワーク Cisco、Dell、Paloalto、F5 OS・仮想化 LinuxOS、VMware、Nutanix、Docker、K8S MW PostgreSQL、Apache、Tomcat、Nginx、PaceMaker、etc... IaC Ansible、Terraform その他ツール Git、Rundeck 運用・監視 Zabbix、Grafana、Prometheus、ArgoCD AI GitHub Copilot、ChatGPT、Devin、Claude、Gemini ※2026年7月時点での情報です。 プロダクトデザイナー フロントオフィス・バックオフィスの業務システムにおける管理画面のUI/UX設計を担当しています。 業務ドメインの理解を深め、ユーザーの声を直接収集しながら課題を把握し、複雑な業務をUI/UXの力でシンプルに解決することを目指している組織です。 また、AI活用による設計業務の効率化、サービス横断での一貫した体験を実現するデザインガイドラインの策定、さらにデザイン組織としての勉強会やナレッジ共有にも取り組んでいます。 カテゴリ 技術スタック デザインツール Figma コミュニケーションツール Slack、Zoom、Google Meet、FigJam AI（業務支援） GitHub Copilot、Claude Code、Cursor、ChatGPT、Notebook LM、Gemini ※2026年7月時点での情報です。 4. 終わりに 最新の技術スタック、あなたの得意な技術や、挑戦してみたい武器はどこかに見つかりましたでしょうか？ ラクスがこれほどまでに技術スタックをオープンにし、長年愛されている歴史あるプロダクトであっても現状に甘んじず変化を続けさせているのには、明確な理由があります。それは、私たちのミッションが「ITサービスで企業の成長を継続的に支援」することだからです。 技術はあくまで、誰かの課題を解決するための素晴らしい手段です。しかし、最高の手段をエンジニアが持たなければ、お客様に最高の価値を届けることはできません。 だからこそ私たちは、これまで培ってきた圧倒的な安定基盤を深くリスペクトしつつも、時代に合わせたインフラの進化や、AIを活用した開発体制へのアップデート、品質を支える仕組みづくりに注力しています。 「自分が今まで培ってきたスキルを、このクラウドサービスで活かしてみたい」 日々進化する技術を積極的に取り入れ、自社プロダクトの未来を共に創り上げていきたい。 そう少しでも感じていただけたなら、その力をぜひラクスで発揮してみませんか。 最後までお読みいただき、ありがとうございました。

こんにちは！AIエージェント開発課です。 近年、生成AIの進化スピードは凄まじく、単なるテキストの要約やドラフト生成の枠を超え、自律的に判断してタスクを実行する「AIエージェント」が大きなトレンドとなっています。 このような技術的な潮流の中、私たちのチームは2025年5月に「AIエージェント開発課」として産声を上げました。累計導入社数 約20,000社以上の顧客基盤と、16年以上にわたって蓄積された膨大な業務データ（ドメイン知識）というラクスの強みを活かし、バックオフィス業務の「完全自動化」という未来へ向けて、日々泥臭く開発を続けています。 私たちがメインで取り組んでいるのは、主力プロダクトである「楽楽精算」へのAIエージェント機能の実装です。 この記事では、私たちが直面した「3つの壁」とそれを突破した設計原則、そしてそこで得られた知見を社内の他プロダクトへ共通LLM基盤として還元していくファーストペンギンならではの面白さについて、生々しい試行錯誤のプロセスを交えてお届けします。 「プロダクトへAI機能を実装してみたいけれど、何から手をつければいいかわからない」「大規模言語モデル（LLM）の不確実性を前にアーキテクチャ設計で立ち止まっている」というエンジニアの皆さんに、明日から試せるヒントとして届くことを願っています。 ラクス最先端の挑戦を担う「AIエージェント開発課」とは 主力プロダクト「楽楽精算」をAIネイティブへ進化させるミッション 理想と現実。リリースへ向けて立ちはだかった「3つの壁」 【コストの壁】大規模クラウドサービスならではの推論量とLLM費用の問題 【精度の壁】個社ごとに異なる複雑な社内ルールにどう寄り添うか 【応答速度の壁】完了までの待ち時間、ユーザー体験を損なわないための葛藤 技術的工夫で壁を突破した「設計原則」 「ルールを考えさせる」から「お手本を真似させる」への転換 AIの不確実性を受け入れ、既存のルールベース機能と組み合わせるハイブリッド構成 「定期起動」から「イベント駆動」へ。非同期アーキテクチャ進化の裏側 ファーストペンギンとして「共通LLM基盤」を検証・構築する面白さ ビジネスロジックと責務を分離する「LLMゲートウェイ」の構築 他チームのコンパスとなる「オブザーバビリティ（監視基盤）」の検証・構築 楽楽精算での検証が、他プロダクトの道標になるダイナミズム 技術を「机の上から社会の中へ」実装したいエンジニアへ ラクス最先端の挑戦を担う「AIエージェント開発課」とは AIエージェント開発課は、エンジニアだけでなくUXデザイナーやビジネスサイドのメンバーも内包する、9名のクロスファンクショナルな少数精鋭チームとして立ち上がりました。 従来のラクスの開発スタイルは、「熟考を重ねた綿密な設計と、確実な法要件対応」を最大の強みとしていました。しかし、数日単位で前提が変わる現在のAI領域においては、既存のやり方に縛られない高速な試行錯誤（仮説検証ループ）が求められます。 そこで私たちは、顧客の「一次情報」に最も早くアクセスできるよう、開発本部の枠からあえて飛び出し、ビジネスサイド直結の組織という特異な構造を選択しました。職能の垣根を完全に取り払い、顧客ヒアリングの結果を受けて全員でUI/UXの改善案を出し合うような「オールラウンド型チーム」を醸成するのが狙いでした。 ※現在はファーストリリースを終えたため、開発本部へ戻っています。 主力プロダクト「楽楽精算」をAIネイティブへ進化させるミッション 私たちが最初に課されたミッションは、「楽楽精算」における経費申請ワークフローの自動化、すなわち「伝票作成AIエージェント」の開発です。 従来の経費精算では、申請者がスマートフォンなどで領収書をアップロードした後、自ら手作業で関連する事前申請やクレジットカードの利用明細をデータの山から探し出し、それらを一つひとつ目視で確認しながら紐付ける必要がありました。この「めんどくさい」「煩わしい」という体験を、AIエージェントの力で根本から変えることが私たちの目的です。 利用イメージとしては、ユーザーが領収書を選択するだけで、AIエージェントがその内容を意味的に推論し、関連するデータを裏側で自動的に探し出して申請用の伝票の下書きを作成します。申請者は、最後に「内容を確認するだけ」という、入力作業ゼロの世界を目指す挑戦が始まりました。 理想と現実。リリースへ向けて立ちはだかった「3つの壁」 「領収書を投げれば、AIが考えていい感じに伝票をつくってくれる」と言葉にするのは簡単ですが、いざ本番運用を前提とした開発に着手すると、AIならではの不確実性と、大規模なプロダクトゆえの制約が、重い壁となって私たちの前に立ちはだかりました。 【コストの壁】大規模クラウドサービスならではの推論量とLLM費用の問題 最初の壁は「コスト」でした。 LLMに対して、領収書データ、事前申請の候補リスト、個社ごとの勘定科目マスタ、さらには過去の申請履歴といった大量のコンテキストを愚直に流し込んで推論させると、1リクエストあたりのトークン消費量が爆発的に跳ね上がります。 検証段階でLLM費用の試算を行った際、このまま数万社という規模のお客様に機能を提供すれば、莫大な運用コストが発生し、事業継続性（Viability）が破綻しかねないという現実に直面しました。 【精度の壁】個社ごとに異なる複雑な社内ルールにどう寄り添うか 2つ目の壁は「精度」です。 経費精算というドメインは、法規制だけでなく、「この部署のこの用途なら勘定科目は交際費にする」「交際費の備考欄には必ず同席者の氏名と人数を記載する」といった、企業ごとに異なる明文化しづらい独自のルールが無数に存在します。この独自ルールが汎用的なLLMモデルでの推論精度に大きく影響しました。 【応答速度の壁】完了までの待ち時間、ユーザー体験を損なわないための葛藤 3つ目の壁は、ユーザーが体感する「応答速度（パフォーマンス）」でした。 伝票作成のワークフローの中で、データの検索、仕訳の推論、構造化出力の生成など、複数回のLLM呼び出しを同期的に（順番に待ちながら）実行する設計にしていたため、画面のローディングが完了するまでに最低でも5～15分という、とてつもない時間がかかってしまうことが判明しました。 その結果、画面遷移を同期的にすると「自分で入力した方が早い」という感想を持たれてしまったのです。この応答速度の遅さは、リリースを阻む最大のボトルネックとして私たちの前に横たわっていました。 技術的工夫で壁を突破した「設計原則」 これらの課題に対して、私たちは「最新のモデルをただ叩く」というアプローチを捨て、ラクスが大切にしてきた「顧客志向（誰のどんな課題を解決するか）」の原点に立ち返り、泥臭いアーキテクチャの変更と設計原則の再定義を行いました。 「ルールを考えさせる」から「お手本を真似させる」への転換 開発が大きく前進したブレイクスルーは、β版公開後のタイミングで導入した「ベクトルDBを用いた過去伝票のコンテキスト注入」でした。 それまでは、LLM自身に「複雑な社内規定や多様な仕訳ルール」を解釈させてゼロから深く推論させようとしていましたが、これでは推論の難易度が上がり、精度が出ないばかりか処理コストも膨らむ一方でした。 そこで私たちは、アプローチを転換しました。過去に確定した膨大な伝票データから、ベクトルDBを用いて「申請者本人が過去に作成した、今回と最も類似している確定伝票（真に正しいお手本）」を高速に検索。そのお手本データをプロンプトの「コンテキストとして補強する」RAGアーキテクチャを採用しました。 LLMに高度なルール解釈を強いるのをやめ、目の前に提示した正しいお手本を「そのまま真似しなさい（Few-Shot）」と指示する。この設計により、LLMが迷うことなく一瞬で正確な伝票を作成できるようになり、精度が劇的に向上しました。さらに、深く考えさせるプロセス（推論の難易度やループ回数）を大幅に下げられたことで、高額な推論コストをカットし、LLM費用を当初の数十分の一にまで抑え込むことに成功したのです。 AIの不確実性を受け入れ、既存のルールベース機能と組み合わせるハイブリッド構成 精度の壁を乗り越えるための私たちの結論は、「AIに完璧を求めない」ということでした。ハルシネーションをプロンプトだけで完全に防ぐのは不可能です。 そこで、AIの責務を「高速にドラフト（下書き）を作成すること」に特化させ、出力されたデータの正当性の担保は、「楽楽精算」が元々持っている強力なルールベースの「規定違反チェック機能」に委ねるというハイブリッドな構成を採用しました。 AIが推論した結果に矛盾や規定違反があれば、既存の強固なシステムが検知して申請前に画面上でユーザーに「確認」を促します。人間が最終的な「確認・承認」の責任を持つ「Human-in-the-Loop」の思想を取り入れたことで、AIの利便性を活かしつつ、業務システムとしての絶対的な安心感と確実性を担保することができました。 「定期起動」から「イベント駆動」へ。非同期アーキテクチャ進化の裏側 応答速度の課題は設計段階からある程度想定していました。伝票作成のような重い処理をユーザーを待たせながら同期的に実行するのは現実的ではないと早い段階で判断し、当初からAWSの「Amazon SQS」を用いた非同期処理をアーキテクチャの前提としていたのです。 とはいえ、ファーストリリース時点では、キューに溜まったリクエストを一定間隔で確認しに行く「定期起動」方式で処理を捌いていました。ところがベータ版として実際にユーザーに使っていただくと、この定期起動の間隔そのものが待ち時間のボトルネックとなり、「思ったより遅い」という声が集まってきたのです。 そこで私たちは、Kubernetesのイベント駆動型オートスケーラーである「KEDA」を導入。キューに溜まった未処理の伝票作成リクエスト数に応じて、K8s jobをスケーリングする仕組みへと進化させました。 この改善を反映したベータ版をリリースした結果、ユーザーは領収書を「まとめて一括で投げる」だけで、ローディングを待つことなく次の画面へ進めるようになり、AIの処理が裏で完了したものから順次、確認・申請ができるという圧倒的にスムーズな体験（従来比約40%の工数削減）へと昇華させることができました。 ファーストペンギンとして「共通LLM基盤」を検証・構築する面白さ 私たちAIエージェント開発課のミッションは、単に「楽楽精算」の機能を良くすることだけではありません。ラクス開発本部のビジョンである「AIネイティブな開発組織への変革」を牽引するファーストペンギンとして、自ら検証したアーキテクチャを全社の「共通LLM基盤」として型化し、波及させていくことに大きなやりがいがあります。 ビジネスロジックと責務を分離する「LLMゲートウェイ」の構築 開発を進める中で、各プロダクトのアカウントから外部のLLMプロバイダーへ直接APIを叩きに行くと、リトライ制御やモデルのバージョン管理、レートリミット対策がアプリケーションコード内に散らばり、保守性が著しく低下するという課題が見えてきました。 そこで私たちは、独立した抽象化レイヤーとして、プロキシ層となる「LLMゲートウェイ」をAmazon EKS上に構築しました。 ここでは、プロバイダーのAPI障害が発生した際に、自動で別リージョンや別モデルへリクエストを切り替える「フォールバック制御」や、一時的なネットワークエラーに対するリトライ処理を一元管理しています。アプリケーション側のビジネスロジックから外部AIへの依存性を完全に分離したことで、外部APIとの接続に関わる改修コストを最小限に抑える足回りを構築しました。もちろん、モデルを差し替えたからといって、そのまま期待通りに動作するとは限りません。モデル固有の出力特性やハルシネーションの傾向変化に伴い、アプリケーション側でのプロンプトの微調整や追加のバリデーション改修は必要になりますが、そうした検証と変更のサイクルを素早く回すための強固な土台となっています。 他チームのコンパスとなる「オブザーバビリティ（監視基盤）」の検証・構築 AIエージェントが本番環境で「今、どんな推論をして、なぜそのエラーを起こしたのか」を追跡する仕組み（トレース収集）は、プロダクト運用において死活問題となります。 私たちは、OpenTelemetry（OTel）Collectorを活用したログ・メトリクス・トレースの収集基盤を他プロダクトに先んじてEKS上に検証・構築しました。 当初、AWS Distro for OpenTelemetry（ADOT) Collectorと呼ばれる配布ディストリビューションを利用していましたが、必要なプラグインが不足していたため、自分たちでカスタムビルドを行うなど、かなり泥臭い対応も経験しています。 この基盤により、Amazon CloudWatchのダッシュボード上に、リアルタイムでのトークン消費量やエラーレート、エージェントの推論プロセス（トレース）が綺麗に可視化できるようになりました。 楽楽精算での検証が、他プロダクトの道標になるダイナミズム 私たちが「楽楽精算」の伝票作成AIエージェントを通じて血を流しながら検証したこれら「LLMゲートウェイ」や「オブザーバビリティ基盤」のアーキテクチャマニフェストは、開発本部全体へ展開され大きな反響を呼びました。 個別最適のサイロ化に陥りがちな複数プロダクトの開発組織において、自分たちの小さな試行錯誤が、数百名の開発体験（DevEx）を一気にAIネイティブへと変革していく「全体最適」のダイナミズムを肌で感じられることこそが、この課で働く最大の面白さだと断言できます。 これら取り組みについては、Amazon Web Services ブログに寄稿した記事にも詳細がございます。ぜひ、ご覧ください。 aws.amazon.com 技術を「机の上から社会の中へ」実装したいエンジニアへ ラクスのAI開発の根底にあるのは、論文の精度を競う研究ではなく、日々の業務の中で実際に動くシステムをつくり、数万社のお客様の働き方を変えていくという「実装主義」の思想です。 AIエージェントという不確実で正解のない未知の領域だからこそ、私たちは完璧を待つよりも、仮説を立てて小さく試すスピードを何よりも大切にしています。 私たちが構築した足回りはまだ完成形ではありません。2030年の「完全自動化」という高いゴールに向けて、これからさらに「個社別のルール最適化」や、「領収書収集から伝票作成までの自動化」、「共通LLM基盤」の整備など、エキサイティングな課題への挑戦が続いていきます。 「AIの力で、働く人の日常を本質的に『楽！』にしたい」 「最先端の技術を自らの手で社会のインフラへと落とし込んでみたい」 そんな熱い顧客志向とAIネイティブな視点を持ったエンジニアのあなたと、これからのクラウドサービスの新しい常識を一緒に創り上げていける日を、AIエージェント開発課一同、心から楽しみに待っています！

こんにちは、ラクスでバックエンドエンジニアをしている斉田真也（GitHub: shinya / X: @saita_shinya）と申します。業務のかたわら、Markdownエディタ Bokuchi を個人で開発していて、仕事でも個人開発でも、いまやClaude Codeはすっかり相棒になっています。 先日大阪の梅田で開催された Claude Code Meetup Osaka に参加し、LT枠でも登壇してきました。AIは失敗する。でもその失敗を"使い捨て"にせず記録して次に読ませれば、二度目から同じつまずきを繰り返しにくくなる ── 私が登壇で話したのは、そんな「Claude Codeの育て方」でした。 この記事では当日の様子と学びを、この会ならではの空気感とあわせてレポートします。 TL;DR 大阪・梅田で開催された Claude Code Meetup Osaka に参加し、LT枠でも登壇してきました。 このMeetupは「技術そのもの」より 「業務の困りごとをClaude Codeでどう解いたか」 という一段上のレイヤーの話が中心。並列エージェント・YouTube運営・資料作成など、活用の幅広さに驚かされました。 私のLTは 「失敗を資産に変えるClaude Code」 ── 却下・失敗をログに残してナレッジ化し、 CLAUDE.md のルールだけで"育てる"運用の紹介です。 参加者の層が幅広く、いわゆる技術勉強会より開かれた雰囲気だったのも印象的でした。 目次 TL;DR 目次 結論：ここは「技術の話」より「仕事の困りごとと解き方」の会だった イベント概要 登壇：失敗を資産に変えるClaude Code 登壇資料 大きな知見となった失敗の例 その他の失敗例 勉強になった他の登壇 手塩にかけりゃいいってもんじゃない ── Claude Code 並列エージェント4つの"面倒の見方"（ming さん） Claude Code と回す、YouTube運営のPDCA（masaya_nishigaki さん） 「コーディングだけじゃない」Claude Code活用術（おってぃ さん） 懇親会：「普段AIをみんな、どう使ってるか？」 所感：一段上のレイヤーの話と、参加者層 余談 まとめ 結論：ここは「技術の話」より「仕事の困りごとと解き方」の会だった 普段、言語やフレームワークの勉強会に行くと、どうしても話題は技術そのものに寄りがちです（それはそうですね）。ですがこのMeetupは、 「自分の業務でこんな困りごとがあって、それをClaude Codeでこう解決した」という、一段レイヤーの高い話 が中心でした。 コーディングにとどまらず、マネジメント・広報・YouTube運営まで、活用の幅の広さに驚かされた一日でした。 イベント概要 項目 内容 イベント名 Claude Code Meetup Osaka 日時 2026年6月17日（火）19:00〜21:00 会場 Blooming Camp by さくらインターネット（グラングリーン大阪 JAM BASE 3F） 主催 AI Agent User グループ（AIAU） イベントの流れ 最初にLTの発表→懇親会で交流 余談ですが、会場の場所が最初全然分からず、梅田のグラングリーンをしばらくさまよってからなんとかたどり着きました・・・。新しくできた街の区画は、慣れるまで迷子になりがちですね。同じ会場を目指す方はお気をつけて。 登壇：失敗を資産に変えるClaude Code 私はLTの2番手として 「失敗を資産に変えるClaude Code」 というタイトルで登壇しました。せっかくなので、少しだけ中身を紹介します。 登壇資料 この資料で言いたかったことは全然シンプルな話で、 「AIは失敗する。でも失敗を記録して次に読ませる仕組みがあれば、二度目から同じ失敗を繰り返しにくくなる」 というものです。ここで大事なのは、モデル自体が賢く再学習するわけではないという点です。やっているのは、失敗の理由を外部ファイル（ナレッジ）に残しておき、 次の提案の前に毎回それを読み込ませる という運用の工夫にすぎません。しかもこれを、コードを一切書かずに CLAUDE.md に書いたルールだけ で回しています。 仕組みは大きく5ステップのループです。 自分による依頼をClaudeが受けたら request_log に記録する 自分の反応（「ありがとう」「ちょっと違う」など）から採用/微妙/却下を検知する それを点数（1.0 / 0.5 / 0.0）として evaluation_log に記録する 却下・微妙がついたら、その理由をカテゴリ別のナレッジに1行抽出する 次の提案の前に必ずそのナレッジを読み込む（さらに毎朝GitHubへ自動push） ポイントは、 評価のために特別な操作は何もしない ことです。普段どおり会話しているだけで、その裏で点数がつき、失敗の理由が蓄積されていきます。 3ヶ月ほど運用して、こんな感じの結果になりました。 項目 数 依頼ログ 約240件 ※ 評価ログ 122件 ナレッジ（カテゴリ数） 8カテゴリ うち却下 12回（約1割） ※ 実際のやり取りの回数ではなく、「依頼した仕事」の単位だと思ってください。 却下は12回（約1割）と数としては少ないのですが、 この12回こそが一番の財産 になります。 大きな知見となった失敗の例 この仕組みを使い始めてから、いちばんヒヤリとしたのが、 勝手にcommit & pushまで進んでしまった 件です。作業が一段階済んだ時点で勝手にコミットをして、そのままpushまでClaudeが完遂してしまってました。 別にコード的に問題はなかったので、結果的には大事に至りませんでした。 人間なら「この状態で確定していいかな？」と一度立ち止まって確認する場面です。自分がするときでもそうします。「未確定の情報が現れた時点で相談すべき」という却下は、いま読み返しても一番の教訓になっているなと思います。ただ、その影響で自分が使っているClaudeはなにか作業が終わるたびに「次はあなたが確認する版です。私はコミットはしません」と毎回くどいように言ってきます（笑） その他の失敗例 他にも、以下のような失敗がありました。 頼んでいないのに先に進む ── 「原因は？」と聞いただけなのに、修正コードまで書いてしまった。依頼スコープの越権で却下。 不十分な数字で判断を誤らせかけた ── リポジトリ内で増大するライブラリのサイズを圧縮後の3.1MBだけとClaudeが伝えてきたが、実際は展開後8.2MB。この差が許容できず見送りに。 こうした却下を「その場で直して終わり」にせず、理由をナレッジに1行残して次から回避する。 失敗が使い捨てから資産に変わる 、という話でした。 こうした運用ルールも、失敗ログも、ラクスの業務の中で蓄積されていったノウハウのおかげでもあります。人が失敗したことを繰り返さないようにする仕組みを、AIにも適用したイメージですね。 冒頭で触れた自作の Bokuchi （OSSのMarkdownエディター）の開発を通じてClaude Codeを酷使する中で溜まっていったものも中にはあります。ちなみに、この発表したスライド自体もBokuchiで書いています。個人でこういうツールを作って回せるのも、日々AIに助けられている延長線上にあるなと感じますね。 勉強になった他の登壇 手塩にかけりゃいいってもんじゃない ── Claude Code 並列エージェント4つの"面倒の見方"（ming さん） Claude Codeで 複数のエージェントを同時に起動して処理を任せる ときの実践的なTips集でした。 「並列にすればいいってものじゃない、面倒の見方がある」というタイトルどおり、どこで手綱を握り、どこを任せるかの勘所が、ご本人の経験値とセットで語られていて説得力抜群！これまで基本シングルエージェントで使ってきた自分にとっては、まさに次に試すべき具体的な引き出しが一気に増えた時間となりました。 まさに参加してよかったの一言。 資料: https://speakerdeck.com/ming_ayami/shou-yan-nikakeriyaiitutemonziyanai Claude Code と回す、YouTube運営のPDCA（masaya_nishigaki さん） 驚いたのは、 コマンド一発でエージェントのオーケストレーションが始まる 仕組みでした。 ご自身で運営するYouTubeチャンネルの登録者数を増やすため、目標管理などのマネジメント業務にAIを組み込んでおられて、まるで優秀な秘書に段取りを任せているかのよう。コーディング以外の「運営」領域でここまで回せるのか、というのが一番の発見でした。 チャンネル: https://www.youtube.com/@masayan-ai-hack 「コーディングだけじゃない」Claude Code活用術（おってぃ さん） エンジニアというよりマネジメント側の視点から、 仕様書や各種資料の作成にAIを活用する ノウハウを語られていました。すでにお気づきの方もたくさんおられるとは思いますが、「AIはコードを書く道具」という先入観を、良い意味で外してくれる内容です。開発の現場だけでなくドキュメント業務にも自然にAIが溶け込んでいくのだと、活用の裾野の広さを実感しました。 懇親会：「普段AIをみんな、どう使ってるか？」 LTのあとは懇親会へ。参加されていたエンジニアの方々と交流しながら、自作のBokuchiを紹介したり、みなさんが普段どんな仕事でどうAIを活用しているかを聞いて回りました。 多くは私たちと同じく開発業務での活用でしたが、中には 親子で参加されている方 もいて、日常の中でのちょっとしたツール開発に役立てているという話も聞けました。用途の広がりを実感します。 所感：一段上のレイヤーの話と、参加者層 冒頭で書いたとおり、業務の困りごとベースの話が中心のイベントでした。 その影響もあってか、 参加者の層がとても幅広かった のも印象的です。女性の参加者も多く、エンジニア以外の職種の方や、前述の親子連れの方まで、いわゆる「技術勉強会」のイメージより開かれた雰囲気でした。 会場のBlooming Campは、さくらインターネットさんが運営するコミュニケーションハブのようなイベントスペースで、今回のような勉強会以外にも様々な使われ方ができそうな、可能性を感じる場所でした。 ちなみに、次回の開催が7/10にあるのですが、これにもまた参加（LTも登壇！）してきます。 余談 最後に、この日いちばん予想外だった話をするのですが、私はカードマジック（手品）がとても好きなのですが、会場を提供してくださったさくらインターネットのエンジニアの方の前職が、なんと 手品関係の会社 だったそうで。「その業界からエンジニアへの転職ってあるんだ」と、思わぬところで人の経歴の面白さに触れた一日でした。 まとめ 自分が普段よく参加してる技術一辺倒の勉強会ではなく、「AIをどう仕事の相棒にするか」を各人の実体験ベースで持ち寄る、学びの多いMeetupでした。 並列エージェント、運営へのAI活用、資料作成・・・持ち帰った宿題も色々ありました。運営のみなさま、登壇者のみなさま、会場を提供してくださったさくらインターネットの方々、ありがとうございました。 今回LTで話した「失敗をナレッジに残して育てる」やり方は、もともと自分の業務の中で試行錯誤して形にしたものです。ラクスは複数のプロダクトを抱えていて、チームごとにAIの使いどころも工夫の仕方も違います。そういう各自の工夫を持ち寄って共有できる余地があるのは、個人的に面白がっているところです。こうした社外の学びも持ち帰りつつ、「AIを相棒として育てる」ことを一緒に面白がれる方と、どこかの勉強会でお会いできたら嬉しいです。

「自分が時間をかけて作った機能、ちゃんと使われていますか？」 エンジニアだったら、たぶん一度は胸の奥に刺さる問いだと思います。仕様書通りに作って、テストも通って、リリースして。でも数か月後にログを見るとあまり利用されていない。そういった経験があるかと思います。 この記事では、冒頭の問いに対して「ちゃんと使われている」と言える機能を開発できた事例を紹介します。 AIを活用することで2週間でベータ版提供までこぎつけ、楽楽自動応対の翻訳機能が最終的に「この機能の導入前にはもう戻れない」と顧客に言ってもらえるまでの裏側です。 実際の業務フローをヒアリングすることで機能への解像度を上げた 社内の認識合わせを動くものを見ながら行った ベータ版は"きれいな設計"より"速く出せる"を優先した 出す前と出した後、2回顧客に見てもらうことでブラッシュアップした 裏側でログを取っておくことで、定量的な観測が出来るようにした 顧客の業務を理解して、初めて使われる機能が出来る 実際の業務フローをヒアリングすることで機能への解像度を上げた 翻訳機能については以前から要望としていただいており、社内で一度モックを作成したことがありました。ただ、社内で翻訳機能を使ったメール送信を行う機会がなく、正解が見えない状態となっていました。 そこで翻訳機能について、1日に届く問い合わせメールが約300件あり、英語 / 中国語 / 韓国語でも問い合わせがある企業に対してヒアリングを行いました。日本語以外のメールが届いた場合の業務フローを伺うと下記の流れになっていました。 外国語のメールを受信 メール本文をコピー 外部翻訳ツールを開く メール本文を翻訳ツールに貼り付け 翻訳結果を確認し、内容を理解 日本語で返信文を作成 返信文を翻訳ツールに貼り付けて外国語に翻訳 翻訳結果をメール返信にコピー＆ペーストして送信 手順として8ステップあり、また別ツールを活用するため、ウィンドウの行き来やコピペが大変だという声を頂きました。 「メール対応のツール自体に翻訳が組み込まれていたら、どれくらい嬉しいですか？」という質問に対して、返ってきたのは「すごく助かる」という回答でした。 ここで機能として提供する価値があることがわかります。 社内の認識合わせを動くものを見ながら行った 今までの機能開発では、事業部側が作成した要求仕様書が存在し、その要求に従って開発側が要件定義を行う流れになっています。このような開発の流れでは、どうしても認識合わせに時間がかかり、要件が固まったとしても実装後に見直しが入ることもありました。 ですが、今はAIがあるため、実際に動くものを即座に作成することが出来ます。テキストによる仕様のすり合わせより実際に動くものを見ながら調整したほうが圧倒的に早く、認識のズレが発生しにくいです。また、即座に作ったものに対しての修正も高速で行えるようになりました。 この機能でも最低限必要な機能として「受信メールの翻訳」と「送信メールの翻訳」をできるスクリプトを作成し、認識合わせに利用しました。 これによって作る機能の方向性が社内で一致します。 ベータ版は"きれいな設計"より"速く出せる"を優先した 社内で方針が決まったとしても、実際に顧客に利用してもらわないと作るものが正解かどうかは分かりません。そこで今回の機能は提供する顧客を絞ったベータ版としてリリースする形を取りました。 ただ、楽楽自動応対は25年の重みがあるプロダクトであり、機能追加にもリリースにも時間がかかる問題がありました。そのため、最速でリリース出来るようにするには本体部分とは分離する別の方法を取る必要があります。 そこで今回はサブシステムとしてリリースしていた機能に相乗りを行う形でベータ版をリリースすることにしました。このサブシステムは最近リリースした機能であるため、AWS上にコンテナとしてデプロイされており、リリース自体もGitHub Actionsで簡単に行えるようになっています。また、フレームワークとしても機能追加が簡単な形になっています。 全く異なる機能が1つのサブシステムに乗るというアーキテクチャとしてあまり良いとは呼べない状態になってしまいますが、ベータ版という前提のもと、メンテナンス性よりも最速でリリースすることを優先しました。これにより、ベータ版の実装から提供までを2週間で行うことが出来ました。この実装でももちろんAIをフル活用しており、コーディング作業の9割はClaude Codeに任せる形になっています。 出す前と出した後、2回顧客に見てもらうことでブラッシュアップした ベータ版の実装が完了した段階で一度顧客に見てもらう機会を設けました。ベータ版として使っていただく上で逆に機能があることでノイズにならないか、顧客側が使う価値があるのかを確認していただくためです。 実装完了段階では最低限翻訳が出来るようなレイアウトになっていました。 実際に見ていただいたところ、業務で使う上で改善していただきたいポイントをいくつもいただくことが出来ました。これも「認識合わせは動くものを見ながら行う」という部分に通ずるところがあります。実際の画面を見ながら業務でどう活用出来るかを見ていただくことで、実際に使っていただけるレベルにブラッシュアップすることができます。 特に画面のレイアウトについては「使われる機能」にするために貴重な意見をいただくことが出来ました。 初期段階では単純に受信したメールの本文とその翻訳結果、返信文とその翻訳結果という4つを表示する形にしていました。ですが、顧客からは「受信メールの原文は読めないから不要」「返信文の翻訳結果を日本語に戻して、ニュアンスが合っているかを確認したい」「実際に入力した返信文と翻訳結果を日本語に戻した内容は左右に並んでいる方が比較しやすい」との声を頂きました。 このような意見は、実際に現場で使っていただく方だからこそ分かる観点になります。このような細かい部分まで顧客の意見を反映することで「使われる機能」になると思います。 いただいた意見はベータ版提供前にすべて反映できました。顧客の手に渡る前にここまで調整出来たことは、後の定着に大きく効いたと感じています。 また、ベータ版をリリースして1週間ほどしてからヒアリングをさせていただいたところ、提供前とはまた異なる意見をいただくことが出来ました。これもベータ版という形で先行リリースすることで顧客の声を聞くことが出来た例になります。 特に使われると思っていたボタンが逆にあることでノイズになり、使い勝手を悪くしているというのは実際に使っていただいたからこそ分かった部分になります。 このフィードバックがあったからこそ、本リリースの際に必要なボタンを洗い出すことが出来ました。 翻訳機能で利用しているAIについてもフィードバックをいただくことができ、モデルの変更やプロンプトの調整に反映しました。実際のメールに使ってもらったからこそ分かる部分であり、ベータ版を経由せずにリリースしていたら「使えない機能」になっているところでした。 ベータ版として最速でリリース出来る仕組みを採用したからこそ、修正も迅速に反映出来る形を取ることが出来ました。いただいたフィードバックを即座に反映して、数日後には修正版をリリースしました。 いただいた内容を反映した結果、ベータ版では最終的にこのような画面レイアウトになりました。 裏側でログを取っておくことで、定量的な観測が出来るようにした 機能をベータ版としてリリースする上で重要と感じたのがログになります。翻訳機能では、どの画面で機能を利用し、何回翻訳を実行したのか、どのボタンを押したのかを計測出来るようにしました。 ベータ版提供後、定期的にログをチェックしていましたが、ログを見ることで機能が実際に業務で使われていることがよく分かりました。また、業務フローの中で一番使われる場面がどこかを把握することができたため、本リリースの際の参考にもなっています。 ベータ版として使っていただく際はヒアリングによる定性的な内容と共にログによる定量的な観測も重要です。 顧客の業務を理解して、初めて使われる機能が出来る 振り返ってみると、今回の翻訳機能開発で起きていたことは「AIを使って速く作れました」というだけの話ではないと感じています。 今回の開発では下記のような流れを取りました。 顧客の業務フローをしっかり聞いて、何が困っているのかを観察する AIを活用して動くものを即座に組み立て、社内・顧客の双方と認識を合わせていく 実際の業務に乗せてみて、ズレや想定外の使われ方を拾う ログでその直感を裏取りする この流れが噛み合ったからこそ「もうこの機能無しでは業務が回らない！」という意見をいただけたと思います。 AIが効いたのは、主に「形にする」「直す」のフェーズ でした。機能要求を読みながら要件定義書を起こす時間や、PoCに数週間かけて社内合意を取りに行く時間が、今は実装と同時並行で進められます。 コーディングをAIに任せられる時代では、エンジニアの仕事の重心が「機能を実装する」から「機能を考える」に移ってきている 実感があります。 ただ、AIだけで「使われる機能」が作れるわけではありませんでした。実際の業務フローを聞かなければボタンの配置一つ決められないし、ベータ版で現場の声を浴びなければ「ボタンが不要」とは気づけなかった。AIで生まれた時間を、顧客と向き合う時間にきちんと再投資できたことが、今回の機能が定着した一番の理由です。 顧客の業務を理解することと、AIで素早く形にして直し続けること。この2つは別々の話ではなく、お互いを支え合う関係になっていました。AI時代の機能開発のひとつのやり方として、参考にしていただけたら嬉しいです。

「勉強のため」から「持ち帰るため」に変わった アウトカムを意識するようになった 将来の自分たちが楽になるかどうかで見ている レベル300のセッションが「ちょうどいい」と感じた AI一色、そしてフィジカルAIの存在感 まとめ AWS Summit Japan 2026に参加してきました。kazuki kanekoです。 今回で人生2回目のAWS Summit Japanです。 昨年はSIerとして参加していましたが、この1年で自社開発の会社に転職し、今はAIエージェントの開発に関わるチームで働いています。 同じイベントなのに、見え方がかなり変わっていて、自分でも驚きました。 振り返ってみると、変わった理由は「転職したから」というよりも、「自分たちのプロダクトを自分たちで作り、運用し続ける立場になったから」だと思います。特にAIエージェントという、設計判断がそのまま精度や運用コストに跳ね返ってくる領域に関わるようになったことで、技術を見る目線そのものが変わりました。 今回は、そのあたりを書いていきます。 「勉強のため」から「持ち帰るため」に変わった 昨年のAWS Summitは、自分にとってかなり「勉強の場」でした。 こういうAWSサービスがあるんだ こういう構成にすると便利なんだ 知らないことを知る。それだけでも楽しかったですし、十分満足していました。 良さそうなセッションを聞いて、気になったブースを見て、知らないサービスを知る。 昨年はそういう回り方をしていました。 しかし、今回は少し違いました。 今やっている業務に役立つ情報はないか 似たような課題を解決している事例はないか 運用を楽にできるものはないか 競合や近い領域のサービスは何に関心を持っているのか そういう目線で会場を歩いていました。 競合のブースを見に行ったり、同じような事例がないかを探したり。 昨年は、そこまで目的意識を持ってブースを回っていなかったので、自分にとって大きな変化でした。 アウトカムを意識するようになった 目線が変わったのは、セッション選びにも出ていました。 今回は、RDSとAuroraのコスト最適化のセッションを聞きました。 コンピューティング、ストレージ、バックアップの各要素でコストを最適化しながら、パフォーマンスを向上させるという内容です。 以前の自分だったら、たぶん興味を持っていなかったと思います。 昨年までは、コストのことをそこまで強く意識していませんでした。 まずは動くものを作る 構成として成立しているかを見る という感じで、運用コストはその後に考える、くらいの優先度でした。 ただ、今はクラウドサービスを提供している会社で開発しています。 クラウドサービスは作って終わりではなく、ずっと運用し続けるものです。 毎月かかるインフラコストを下げることには、かなりわかりやすい価値があります。 少しの改善でも、長い目で見ると大きな差になります。 なので今回は、 その構成、便利だけど毎月いくらかかるんだろう 性能を落とさずに安くできる方法はないだろうか ユーザー数が増えたらどうなるんだろう という見方をするようになっていました。 将来の自分たちが楽になるかどうかで見ている 開発のしやすさ、運用のしやすさ、変更への強さ。そういう「将来の自分たちが楽になる仕組み」に自然と興味が向くようになっていました。 CI/CDをどう整えると、変更を安全に出しやすくなるのか。 将来ビジネス要件が変わったときに、できるだけ楽に変更できる設計にするにはどうすればいいのか。 SIerにいたときは、こういうことをそこまで自分ごととして捉えられていなかった と思います。 実際にそのシステムを運用するのは自分ではないことも多かったですし、半年後には別のプロジェクトを担当している可能性もありました。 そうなると、どうしても「今のプロジェクトを無難に無事に終わらせること」に意識が向いていました。 一方で、今は自社サービスの開発に関わっています。 開発しづらい仕組みを作れば、あとで困るのは自分たちです。 運用しづらい設計にすれば、問い合わせ対応や障害対応で大変になるのも自分たちです。 逆に、良い仕組みにできれば、その恩恵を受けるのも自分たちです。 ここでいう「楽」は手を抜くという意味ではありません。無駄な作業を減らし、変更の影響範囲を小さくし、リリースを安全にすることです。そういう良い仕組みが、結果的にアウトカムに繋がっていくのかなと思うようになりました。 ただ、SIerの経験があったからこそ見えていることもあると思っています。 SIerでは、自分が書いたコードや設計書を、自分以外の誰かが読み、使い、運用するのが当たり前でした。だから「自分がわかる」ではなく「渡された相手がわかる」を基準にする癖がついていました。 今、AIエージェントの開発をしていても、この感覚はそのまま生きています。別のメンバーが見て意図を理解できるか。半年後の自分が読み返して迷わないか。そういう判断をするとき、SIer時代の「他人に渡す前提で作る」という経験がベースになっていると感じます。 このあたりは、SIerにいたときと自社開発に来てからで、自分の中でかなり変わったところだと思います。 もしこの記事を読んでいるあなたが今SIerにいるなら、一度だけ想像してみてほしいです。自分が作ったシステムを、3年後も自分が使い続けるとしたら、今と同じ設計をするだろうか？と。 自分はその問いに向き合う立場になって、初めて見え方が変わりました。 レベル300のセッションが「ちょうどいい」と感じた 今回、もうひとつ個人的に印象に残ったことがあります。 AIエージェントの精度改善についてのセッションを聞きました。 Architecture・Context・Toolsの各レイヤーで、精度劣化の原因と設計での緩和策を解説するという内容です。 このセッション、レベル300です。 AWS Summitのセッションはレベル200〜400で分類されていて、300は上級にあたります。 以前の自分だったら、たぶんついていけなかったと思います。 ただ今回は、内容が 今の自分にちょうどいい と感じられました。 実際にセッションを聞いて、知っていることの確認になる部分と、新しい設計の視点が得られる部分の両方がありました。 特にAgentが使用するToolsはどうしても増えがちだと思っているので、関連性の低いToolsをそもそもAgentに渡さないという設計の観点を手に入れられたのはよかったなと思います。 普段の業務でAIエージェントの開発に関わっているからこそ、このセッションの内容が「知識」ではなく「明日使える設計判断」として入ってきました。 その「ちょうどいい」という感覚自体が、この1年での成長を感じる瞬間でした。 AI一色、そしてフィジカルAIの存在感 昨年もAI関連の展示やセッションは多かったです。 ただ、今年はもう一段階進んでいました。 AWS Summitというより、「AWS AI Summit」と呼んでもいいのではないかと思うくらい、AI一色でした。 体感としては、ほとんどすべてのブースに「AI」という文字が入っていたように思います。 少し大げさかもしれませんが、それくらいAIが前提になっていました。 昨年はまだ「AIをどう使うか」というテーマが多かった印象です。 今回はそれに加えて、 AIを業務にこんな感じで組み込んでみました 自社用にカスタマイズしたAIを作りませんか AIを現実世界にどう適用するか という話が増えていました。 特に印象的だったのがフィジカルAI です。 ロボットやカメラ、現実世界のデータとAIを組み合わせるような展示が多く、AIがソフトウェアの中だけに閉じなくなってきている感じがしました。 昨年の自分は、AIというとPCの中で閉じていて、チャットAI、AIエージェントのようなものをイメージすることが多かったです。 今回は、それに加えて、現実世界に干渉できるハードに乗ったAIが増えてきました。 もちろん、まだすべての企業がすぐに導入できるという話ではないと思います。 ただ、性能面、安全面、コスト面を考えても、企業が現実的に検討できるラインに近づいてきているのかなと感じました。 今までは「研究っぽい」「デモっぽい」と感じていたものが、少しずつ業務に入ってきそうな雰囲気があります。 まとめ 人生2回目のAWS Summitでしたが、去年とはかなり違う見え方をしました。 去年は「知らないことを知る場」だったのが、 今年は「持ち帰って使う場」 になっていました。コストを意識するようになり、将来の運用を見据えた設計に興味が向くようになりました。 この変化は、自分たちのプロダクトを自分たちで作り、運用し続ける立場になったことから来ていると思います。作ったものの結果を自分たちが引き受けるからこそ、技術の見え方が変わりました。 会場の人もかなり多く、昨年も雨でしたが今年も雨で、それでも体感1.5倍くらいの人がいた気がします。 来年参加するときには、また違う視点で見ている気がします。そのとき自分がどんな問いを持って会場を歩いているのか、今から少し楽しみです。

1. はじめに この記事で書くこと この記事で書かないこと 前提 2. バージョンアップ作業フロー Step 1：メジャーバージョンアップによる影響調査 Devin の Playbook を作成する Devin の Playbook を実行して一覧化する Step 2：対応が必要かどうかの判断と方針検討 Step 3：更新作業 3. AI 活用の所感 影響度判定の精度評価 良かった点 微妙だった点・反省 4. まとめ 5. 今後の展望 参考文献 1. はじめに ラクスが開発する請求書受領システム「楽楽請求」では、Web アプリケーションフレームワークとして Spring Boot を使用しています。 当時使用していた Spring Boot の 3 系 が2026年6月で EOL になるため、バージョンアップ（3系 → 4系）を実施しました。 バージョンアップに関する影響調査を AI（Devin）に任せてみたので、その実践内容を共有します。 この記事で書くこと メジャーバージョンアップの影響調査を AI に任せる具体的なやり方 どこまで効いて、どこは人間が必要だったか この記事で書かないこと メジャーバージョンアップ対応自体の詳細 前提 今回のバージョンアップ対象は以下のとおり。いずれもメジャー更新。 ※Spring Boot に依存するライブラリなどのバージョンアップを含む 対象 Before After Spring Boot 3系 4系 Spring Framework 6系 7系 Jackson 2系 3系 2. バージョンアップ作業フロー 今回行ったバージョンアップ作業フローは大きく分けて以下の３ステップです。 Step 作業内容 自動化レベル 1 メジャーバージョンアップによる影響調査 自動 2 Step 1 の調査結果から対応が必要かどうかの判断と方針検討 手動 3 更新作業 ほぼ手動 Step 1：メジャーバージョンアップによる影響調査 Spring Boot やそれ以外の、リリースノートを含めた膨大な情報量を整理して、自プロダクトへの影響を洗い出すStep。 Devin の Playbook を作成する 使用した Playbook（一部抜粋） ### Required from User - mw name: 対象のMW名 - current version: 現在利用中のMWバージョン - target version: アップデート後のMWバージョン ### Procedure 1. mw name と current version, target versionを確認する 2. mw nameで指定されたMWのGitHubリポジトリまたは公式ドキュメントにアクセスする。 3. GitHubリポジトリも公式ドキュメントも存在しない場合、ユーザーにエラーメッセージを返して終了する。 4. GitHubリポジトリまたは公式ドキュメントが存在する場合、そのURLをユーザに返す。両方存在する場合はGitHubリポジトリを優先する。ユーザはURLを受け取った後、次のステップに進むよう指示する。 5. リリースノートページにアクセスし、current versionからtarget versionまでのリリースノートを確認する。 6. 5.で確認したリリース内容の@で指定したリポジトリに対する影響を調査する。 7. 以下の形式で影響調査結果を出力する。1. markdown形式の表 2. CSVファイル - カラム1: バージョン - カラム2: 変更内容(原文) - カラム3: 変更内容(日本語訳) - カラム4: 変更内容種別(ex: 破壊的変更、機能追加、バグ修正など) - カラム5: 影響度(高・中・低・なし) - カラム6: 影響度の根拠 参考： Devin Playbook の概要 - 公式ドキュメント ※使用した Playbook は今回のバージョンアップ用途で作成していないため、Spring Boot のバージョンアップに特化したものではない Devin の Playbook を実行して一覧化する 依存関係がある MW の数だけ繰り返し Playbook を実行する。 対象 MW と前後バージョンを明示し、MW の公式 GitHub リポジトリ or 公式ドキュメントを参照 指定したリポジトリ（今回は楽楽請求リポジトリ）に対する影響を調査 調査結果を一覧化 列 内容 バージョン その変更が入ったバージョン 変更内容（原文） リリースノートの記載 変更内容（日本語訳） 上記の和訳 変更内容種別 破壊的変更／機能追加／バグ修正 など 影響度 高・中・低・なし 影響度の根拠 なぜその影響度と判断したか Step 2：対応が必要かどうかの判断と方針検討 Devinの調査結果を見て実際に対応する必要があるか、どのように対応するかの方針を検討するStep。 変更内容の種別・影響度から、楽楽請求プロダクトへの対応要否を判断 要対応箇所をどのように対応するかを方針レベルで検討 Step 3：更新作業 実際にバージョンアップを行い、破壊的変更に対応するStep。 個別判断が必要な箇所が多く、ほぼ手作業 → ただし、修正パターンが決まりきっている変更はAIに委譲 3. AI 活用の所感 影響度判定の精度評価 影響度「なし」判定が正しかった割合・・・93.5% 影響度「高／中／低」判定が正しかった割合・・・49.3% 良かった点 情報量が多く定型的な 「読む・分類・一覧化」を AI に寄せられた 影響度の根拠まで出力させたことで人間のレビュー判断が速くなった 実際の更新作業でも 機械的な修正を AI に委譲でき、人は判断に集中できた 微妙だった点・反省 AI の影響度判定（特に「中」「低」）に見逃しがあり、鵜呑みにできなかった → だが一次調査としての精度は十分 → AI は「たたき・一覧化」までは強力なので、最終判断は人間が持つ前提で運用する 4. まとめ メジャーバージョンアップの影響調査で、AI は「読む・分類する・一覧化する」までを自動化できた ただし「影響度の判定」はそのまま信用せず、人間の確認を前提に使うのが現実的 作業全体の AI と人間の作業比率は体感で 1:9 程度で、気持ち少し楽できたくらいだった 5. 今後の展望 対応当時は主に一覧化作業にのみ AI を活用していたが、調査〜修正PR作成までを一気通貫で完全自動化する ラクス社内で AI の導入がどんどん進んでいるので、Devin に限らず Claude Code, Codex 等を用いた自動化を検討する 参考文献 Spring Boot サポート期間 Devin Playbook の概要 - 公式ドキュメント