こんにちは！楽楽精算開発部 の 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 の概要 - 公式ドキュメント

はじめに 私が開発ツールに求めることをZedは満たしていた すぐに開けること コードが追いやすいこと 複数画面を上下左右に開けること ディレクトリがツリーで開けること Git関連機能にアクセスしやすいこと VSCode、Ghostty、Zedを比較する Zedの使用感 Zedの微妙なところ ACP経由のエージェント体験はCLIより遅く感じる ファイルパスクリックで開けない VSCode拡張に依存している人は移行しづらい まとめ はじめに 4月にラクスに入社しました。kazuki kanekoです。 研修を受けつつ、開発環境を立ち上げようとVSCodeをセットアップしていました。 すると、AIエージェント開発課のメンバーから「Zedいいですよ」とおすすめしていただきました。 これが、私がZedを知ったきっかけでした。 今は紆余曲折ありながら、Zedに落ち着いています。 以前はVSCodeを中心に使っていて、困っていたわけではありませんでした。 ただ、Zedを使い始めてから、 「VSCodeの動作って、実はけっこう重かったんだな」 ということに気がつきました。 また、Ghosttyについてもおすすめしていただいていたので、一時期はZedとGhosttyを同時に使っていました。 ただ、今は割とZedだけで完結している状態になってきています。 そこで今回は、VSCode、Ghostty、Zedを使ってきたうえで、なぜ今Zedに落ち着いているのかを書いていきます。 まず、前提としてZedについて整理します。 Zedとは、高速性、コラボレーション、AIとの連携を重視して作られているコードエディタです。 公式サイトでは、Zedは「speed」と「humans and AIとの collaboration」のために作られたミニマルなコードエディタとして説明されています。 macOS、Linux、Windowsで利用でき、Rustで一から書かれていて、複数CPUコアやGPUを活用する設計になっています。 Zedを作っているのは、AtomやTree-sitterに関わってきたチームです。 AtomやElectron、Tree-sitterなどの開発経験の延長線上にあるプロダクトとして、Zedが作られています。 Zedの特徴は、単に「軽いエディタ」というだけではありません。 Rust製で、独自UIフレームワークであるGPUIを使い、GPUを活用するような設計になっています。 Zed 1.0の記事では、AtomのようにWeb技術の上に作るのではなく、GPU上のshaderにデータを渡すような、いわばゲームのような作り方を選んだと説明されています。 ソース： https://zed.dev/ つまりZedは、VSCodeのようなGUIエディタの便利さを持ちつつ、より軽く、より高速に動くことをかなり強く意識して作られたエディタだよ、という感じです。 私が開発ツールに求めることをZedは満たしていた 私が開発ツールに求めるのは、以下の５つ すぐに開けること コードが追いやすいこと 複数画面を上下左右に開けること ディレクトリがツリーで開けること Git関連機能にアクセスしやすいこと 順に説明します。 すぐに開けること まず、すぐに開けることです。 GitHubを見ていて、 「このファイル、エディタでちゃんと見たいな」 と思うことがあります。 そういう時にVSCodeで開くと、体感で5秒から6秒くらいかかることがありました。 もちろん数秒なので、めちゃくちゃ遅いというほどではありません。 ただ、開発中の「ちょっと見たい」場面では、この数秒が地味に気になります。 メモ帳みたいにパッと開いて、すぐ見られたらいいのになと思っていました。 Zedはこの「パッと開ける感じ」がかなり良いです。 エディタを開くまでの心理的な重さが少なくて、ちょっと確認したいときにも気軽に開けます。 この軽さは、毎日使っているとかなり効いてきます。 コードが追いやすいこと 次に、コードが追いやすいことです。 コードを読んでいる時には、いろいろな情報を行き来します。 たとえば、 関数の定義元に移動する 型定義を見る クラスやinterfaceの中身を見る 呼び出し元を確認する ファイルをまたいで処理の流れを追う といったことをよくやります。 このときに、定義元にすぐ移動できたり、型ヒントが見られたり、クラス名などにカーソルを当てたときに関連箇所が薄くマーカーされて見やすかったりすると、かなり助かります。 Zedは、このようなIDEの機能を提供してくれています。VSCodeほど充実してませんが、Ghosttyよりは充実しています。 複数画面を上下左右に開けること 複数画面を上下左右に開けることも重要です。 Ghosttyのようなターミナルは、分割の体験がかなり良いです。 上下左右に画面分割できるので、横3、縦2の6画面みたいな形でも開発できます。 Zedでもエディタを上下左右に分割できます。 そのため、Ghosttyのような画面分割の気持ちよさをZedは提供してくれています。 ディレクトリがツリーで開けること ディレクトリをツリーで開けることも大事です。 私は、ディレクトリ構造を見ながら開発したい派です。 たとえば、 controller service repository domain schema migration test のような構成を見るだけでも、そのプロジェクトがどういう責務分割をしているのかがわかるので、どこを変更すればいいのかなどがわかりやすいです。 ZedにはProject Panelがあり、ディレクトリツリーを見ながら開発できます。 Git関連機能にアクセスしやすいこと Git関連機能にアクセスしやすいことも、自分にとってはかなり重要です。 正直、毎回ターミナルで git status を打ったり、commitをコマンドでやったりするのは少しめんどくさいです。 もちろんCLIでやった方が速い場面もあります。 ただ、変更ファイルを一覧で見たり、diffを確認したり、stageする変更を選んだりする作業は、GUIで見たいことが多いです。 VSCodeのGit Graphみたいな感じで、ブランチや履歴を見たり、変更内容を確認したりできるとかなり楽です。 ZedにはGit PanelやProject Diffがあり、変更ファイルを確認したり、diffを見たり、stage / unstageしたりできます。 日常的なGit操作であれば、かなりZed上で確認できます。 VSCode、Ghostty、Zedを比較する ここで、VSCode、Ghostty、Zedを比較してみます。 ただし、Ghosttyはエディタではなくターミナルエミュレータです。 なので、厳密にはVSCodeやZedと同じ種類のツールではありません。 ここでは、以下の3つの開発スタイルとして比較します。 VSCodeのような全部入りGUIエディタ GhosttyでCLIツールを組み合わせてエディタっぽく使うスタイル Zedのような軽量GUIエディタ 観点 VSCode Ghostty Zed 起動の軽さ 重く感じることがある 軽い 軽い コードジャンプ 強い 工夫が必要 強い ファイルツリー ある 工夫が必要 ある 画面分割 できる かなり強い 強い Git UI かなり強い 工夫が必要 強い AIエージェント 拡張＋CLIエージェント CLIエージェント前提 ACP＋CLIエージェント 自分の印象 全部入りだけど、不要な機能も多く重い 軽いが、使いこなすのに工夫が必要 軽さと機能のバランスが良い VSCodeでも普通に困らないなと思います。 拡張機能も豊富で、Gitも見やすく、デバッグやリモート開発なども含めると、かなり全部入りの開発環境です。 なので、VSCodeが悪いという話ではありません。 ただ、自分の使い方では、少し重く感じる場面がありました。 Ghostty中心のCLI開発は、軽さと自由度がかなり良いです。 ターミナル分割もしやすく、AIエージェントとの相性が一番いいと思いました。 AIエージェントが作業完了すると通知が飛ぶのがいいですね。 ただ、私の場合は、コードを追うときに 定義ジャンプ、ファイルツリー、Git diffなどを自然に見たい場面が多かったです。 比較すると個人的にはZedは、そのVSCodeとGhosttyの中間かなと思っています。 Zedの使用感 ここからは、実際にZedの画面を開きながら、使用感を共有できればと思います。 Zedを立ち上げると以下のような画面が開きます。 初めは何にもないです。VSCodeは初回から何やらたくさん出てきますよね。 何も無さすぎて、初めは戸惑うのですが、 画面底の帯部分（赤で囲った部分）に配置されているアイコンをクリックすると、ターミナルだったり、ファイルツリーを開くことができます。 VSCodeっぽく使いたい場合は、 ファイル、git関連機能、ターミナル、Copilotみたいな感じで開くとそれっぽく使えます。 やろうと思えば、Ghostty風の配置もできます。 Zedでこの配置をするメリットはあまりないので、それならGhosttyがいいかなとか思いますが、一応できます。 私の配置は以下の様な感じです。 エージェントを並列で使いたいので、ターミナルを3枚、git関連情報を右側で見ながら、ファイルも開きながらという感じで開発しています。 ブログ形式でZedの使用感を伝えるのは、難しいなと思いつつ、画面構成の自由度の高さだったり、Copilot、ファイルツリー、git関連機能など、ほしい機能は最初から入っていて、使いやすそうだなというのが伝われば幸いです！ 画像では伝わらないですが、今の画面構成を変更したりする操作がサックサクで動く感じです。 Zedの微妙なところ ここまでZedの良いところを書いてきましたが、もちろん完璧ではありません。 特に、AIエージェントまわりはまだ、CopilotやCLIがいいなと感じることはあります。 ACP経由のエージェント体験はCLIより遅く感じる ZedはACP経由で外部エージェントと連携できます。 これは組み込みのAIエージェント機能に依存しないという点で便利なのですが、自分の体感では、ACP経由のエージェント体験はCLIより少し遅く感じることがあります。 CLIでエージェントを使っていると、入力してすぐ反応が返ってくる感じがあります。 一方で、ZedのACP経由だと、UIを挟むぶんレスポンスの出方が少し遅く感じることがあります。 これは設計上ある程度仕方ないのかもしれません。 ただ、CLIの即応感に慣れていると、ここは少し気になります。 ファイルパスクリックで開けない AIエージェントが生成した文章の中に、 src/foo/bar.ts のようなファイルパスが含まれることがあります。 このとき、そのファイルパスをクリックしてそのままファイルを開けると便利です。 VSCodeだと、このあたりの導線が自然に感じることがあります。 一方で、Zedでは、AIエージェント出力内のファイルパスは、ファイルパスのリンクになっていないので、ただの文字列です。 VSCode拡張に依存している人は移行しづらい これはZedというより、VSCodeから別エディタへ移るとき全般の話でもあります。 VSCodeは拡張機能がかなり強いです。 たとえば、 Git関連 Docker Dev Containers Remote SSH デバッグ 各種言語サポート GitLens Copilot など、エディタというより開発プラットフォームに近いです。 なので、VSCode拡張に強く依存している人が、いきなりZedへ全部移行するのは難しいと思います。 私の場合は、VSCodeのすべてが必要だったわけではありません。 だからZedのバランスが合っていました。 まとめ Zedは完璧なエディタではありません。 VSCodeほど何でも揃っているわけではありません。 GhosttyほどCLI開発体験が良いわけではありません。 ただ、色々なバランスを考えると今の私にはZedがかなり合っているという結論になりました。 軽く開ける。 コードを追いやすい。 ファイルツリーがある。 画面分割できる。 Git機能にアクセスしやすい VSCodeに慣れているが、でも、もう少し軽く使いたいという方 Ghosttyの軽さが好きだが、手軽にコードジャンプやGit UIが使いたい方 Zedいいですよ。

まず「測る」ことを設計した 「使わない」には、それぞれの理由があった AI活用は確かに進んだ。でも、浸透しきってはいない 顧客に届けるための、AI活用標準化 今期進める4つの取り組み 「エンジニア非稼働時間帯でも開発が進む」を目指して こんにちは、ラクス技術広報です。 AIツールが開発現場に届いたあと、何が起きているのか。ChatGPT EnterpriseやGitHub Copilotが展開されてしばらく経ったころ、ラクスの開発本部横断組織「開発管理課」はある問いに詰まっていました。ツールは使えている。使っているエンジニアもいる。でも組織として本当に生産性が上がっているのか、確かめる手段がなかった。 実際に声を集めてみると、大きく個人差が開いている状況でした。AIを使いこなしてどんどん先へ進む人と、今まで通りのやり方を続ける人。「チームによって開発スピードに差が出てきている。個人の問題というより、組織として型がないことが課題だと感じていた」と担当者は言います。 ラクスは楽楽精算・楽楽明細・楽楽自動応対など複数のクラウドサービスを展開しており、開発組織は商材ごとに独立したチームで構成されています。チームが独立しているぶん、AI活用のやり方も自然と各チーム任せになりやすく、活用度にムラが出やすい環境でもあります。このムラをどう埋め、組織全体に浸透させるか。開発管理課がどう向き合っているのかを、担当者に語ってもらいました。 まず「測る」ことを設計した 「浸透しているかどうかが見えない」問題を解くために、開発管理課が最初に選んだ一手は計測の仕組みを作ることでした。 参考にしたのはSalesforceが実施していた48項目にわたるAI浸透度調査。ただ、そのまま導入するのは規模が大きすぎる。削り込んでいっても20問ほどになってしまい、それでもまだ多い。さらにラクス特有の難しさがありました。ラクスの開発組織は商材ごとにチームが独立しており、技術スタックも文化も異なる。単一組織向けに設計されたサーベイをそのまま当てはめても、実態を正しく測れない。加えて「どのツールを使っていますか」「その機能は使っていますか」という質問は、ツールや機能が変わるたびに使えなくなる。「変わらない計測軸で、AI導入を継続的に観測するにはどうすればいいか」という問いに、担当者は上長と二人で揉みに揉みました。 行き着いたのが「プロセス別AIコミット度」という設計軸です。実装・テスト・設計・要件定義といった各開発フェーズで、どれだけAIを活用しているかを問う。ツールの名前ではなく「工程への組み込み度合い」を問うことで、環境が変わっても変わらない比較軸を持てるようになりました。これにより、管理職への相談も「感覚値」から「数値に基づく議論」に変わっていきました。 第1回サーベイを実施すると「一歩目を踏み出せていない人が一定数いる」ということが数字としてはっきりしてきました。次の問いは「なぜ使われていないのか」でした。 具体的な計測設計については、2026年1月開催のイベントで詳しく発表しています。 speakerdeck.com 「使わない」には、それぞれの理由があった サーベイを取りながら、担当者は管理職や現場メンバーへのヒアリングも重ねていました。すると、「使わない」には想像以上に多様な事情があることが見えてきました。 担当者の印象に残っているのは、こんな声でした。 「"AI活用してます"とは言いにくい」 エンジニア文化特有の謙遜として、「AIちょっとできます」と名乗ること自体への抵抗感がある。「使っている」と言うのが気恥ずかしく、結果として使っていないように見えてしまう人が一定数いた。 「ハルシネーションでテストが増えて、むしろ手間が増える」 AIを入れると今まで動いていたコードがずれてしまい、テストの修正コストが上回る。「わざわざAIに作り直させると余計に手間が増える」と感じている人がいた。 「試行錯誤の時間が取れない」 高負荷な業務を抱えながら、AIを自分の業務にフィットさせる時間が取れない。「失敗したらまた手直しもしなきゃいけない。片手間でなんとかするのは難しい」という声もあった。 「AIとチャットはするけど、開発業務で効率的に使う方法がわからない」 AIとやりとりすること自体はしている。でも、実際の開発のどの場面でどう使えばいいかイメージが持てず、業務への組み込みは試せていない。気づけば「使っていない人」になっていた。 こうした声を踏まえ、「まず一歩目を踏み出せていない人をケアする」という方針で勉強会を設計しました。GitHub Copilotのベンダー開発者を招いたQA付きセッション、社内のAI推進者によるClaudeの活用ハンズオン。ハンズオンでは「AIとチャットするだけでなく、実際の業務にどう組み込むか」にフォーカスしたプレゼンを行い、参加できなかったメンバーのために動画も社内に公開しました。「特にあまりAIに触れていなかった方々からは『ためになりました』という声が届きました」と担当者は振り返ります。 AI活用は確かに進んだ。でも、浸透しきってはいない 2025年9月の第1回から約5ヶ月後、2026年2月の第2回サーベイでは、開発本部全体のAI生成比率が約15ポイント上昇（43.3% → 58.3%）。「生成比率75〜100%」と回答したエンジニアの割合も30%から50%以上に増加し、AI活用が個人の試みから組織的な広がりに変わってきた手応えがあります。 一部のチームでは、より具体的な成果が出ています。 コミットからマージまでのサイクルタイムが、以前の数分の1以下に短縮された 実装工程の大部分をAIが生成するようになった（実装工程のAI生成比率は60%台から70〜90%台に到達） リリース頻度が倍近くに上がった 「仕様駆動開発（SDD）」の導入で、ある工程の工数が半分以下になった テスト項目書からE2Eテストを自動生成する取り組みで、テスト工程も大幅に削減できた 楽楽明細・楽楽自動応対チームなど一部チームでは、要件定義・概要設計といった上流工程でのAI活用率も20%台から50〜60%超に向上。設計フェーズでもAIが機能する段階に入ってきています ただ、組織全体を見渡すと、AIはまだ浸透しきっていません。商材や個人のスキルによって、活用度にムラがあります。AI活用が進んでいるチームのやり方は、そのチームメンバーの体に染み込んだ暗黙知になっており、「隣のチームでも再現したい」となったとき、そのままでは届きません。「何ができるか」を検証するフェーズは超えた。「組織全体にどう行き渡らせるか」が、今期のスタート地点です。 顧客に届けるための、AI活用標準化 なぜAI活用を組織として標準化するのか。答えは「開発を速くしたいから」だけではありません。 ラクスの開発組織が最も重視している価値観は「顧客志向」です。顧客が抱える業務課題を深く理解し、それを解決するプロダクトを届けること。個人のAI活用では、顧客への価値提供スピードを「組織として」上げるには不十分です。一部のチームの開発スピードが上がっても、全体が変わらなければ、顧客が受け取る価値の差分は限定的です。だからAI活用を「組織の標準」にする必要があります。 AI活用が進んでいるチームを観察すると、スキルや知識だけでなく「どの工程で・どんなインプットを渡せばAIが機能するか」という設計が体に染み込んでいます。これは情報共有だけでは伝わりません。型化の優先順位は「顧客価値に最も直結する工程」から決めています。 今期進める4つの取り組み 以下の4つの取り組みを通じて、全商材で高速かつ高品質な開発プロセスを再現性のある形で確立していきます。 ① AI駆動開発手法の標準化 設計・実装・レビュー・テストで、なるべくエンジニアの介入が要らないAI活用の「型」を統一します。成果が出ているチームの事例を収集済み。仕様駆動開発の型化が進行中。 ② 商材特性に応じた最適化 各工程でのAI駆動開発を磨き込み、より精度の高いAIワークフローを実現します。商材・技術特性に応じて使い方を順次アップデートしていきます。 ③ ナレッジの体系化・横展開 成功・失敗を含む実務レベルの知見をガイド化し、誰でもアクセス可能な形で集約します。キャッチアップの土台を整備し、勉強会支援や情報共有の場も整えていきます。 直近のハンズオン会アンケートでは、「他チームとの密接な情報共有がほしい」という声が50%に上り、事前に最多と予想されていた「技術的なトレーニングやワークショップが必要」と同数でした。知識を増やすことと同じくらい、「隣のチームが何をしているか」を知ることが求められています。 ④ AI活用の浸透度・生産性の可視化 「測れないものは改善できない」という考えから、AI活用の推進状況を可視化する仕組みを整備しました。開発・インフラ・QA・PdM・PDを対象に、各工程でのAI活用状況を定義した「AI活用実践カタログ」です。定性的な「なんとなく進んでいる」から、「ここが遅れている、だから次はこうする」という定量的な議論への転換を目指しています。 「エンジニア非稼働時間帯でも開発が進む」を目指して 一部のチームでは、エンジニアが設計に集中している間にAIが実装を進める状態が見えてきています。非稼働時間帯も開発が動く。そのゴールの射程が、ようやくリアルになってきました。 ただ正直に言うと、型が定まっていない領域はまだ多く、ナレッジの体系化も道半ばです。それでも「組織全体にどう行き渡らせるか」という問いに正面から向き合えるタイミングになってきた、と感じています。 この取り組みについて、もう少し詳しく聞いてみたいという方には、7月15日（水）開催のオンラインイベントの視聴をご検討ください。CTOや執行役員をはじめ複数のエンジニアが、複数プロダクト組織でのAIネイティブ化の実践をリアルに語る場です。無料・オンラインで参加できます。 「CTO登壇」RAKUS AI Conference 2026 Summer

はじめに 楽楽シリーズUI統一プロジェクトとは フェーズ1: AIに任せられない領域 フェーズ2: 規模がもたらした新たな課題 AI活用の勘所: 実装ルールをAIに翻訳する なぜ「セルフチェック」だったか Cursor Rulesという仕組み 運用してみての手応え 振り返って見えたパターン 作業の性質とAI活用の相性 AI活用は、人間の作業との連携で成立する おわりに はじめに こんにちは。楽楽販売の開発を担当しているn-chocolatteです。 「AIを活用しよう」とはよく言われますが、いざ自分の現場に当てはめようとすると、「結局、どの作業に使えばいいのか」で手が止まってしまう。そんな経験のある開発者の方は、少なくないのではないでしょうか。 先にお伝えしておくと、今回私たちがAIを使ったのは 実装そのものではなく、実装後のセルフチェック工程 でした。 なぜそこに使ったのか——その判断の過程を、日々の開発にAIをどう取り込むか模索している方のヒントになればと思い、共有します。 本記事でご紹介するのは、ラクスが掲げる「AIネイティブな開発組織」という方針のもと、楽楽販売開発チームが「楽楽シリーズUI統一プロジェクト」の中で実践したAI活用の一例です。 テーマは「 作業の性質を見極めて、AIの勘所を押さえる 」。 AIに任せられる作業と、人間が責任を持つべき作業を見極め、適切な領域にAIを投入する。 今回のプロジェクトは、そうした判断の積み重ねの記録でした。 楽楽シリーズUI統一プロジェクトとは 「楽楽シリーズUI統一プロジェクト」は、楽楽シリーズの全商材でデザインを統一する、シリーズ横断の大規模な取り組みです。 きっかけはお客様の体験でした。 楽楽精算など他商材をお使いのお客様が新たに楽楽販売を導入された際、見た目や操作感が全く違うと、それだけで戸惑いの原因になります。 同じシリーズなのにデザインがばらついていて使いづらい――この見えない障壁を取り払うのが目的です。 実装としては、各商材が共通のデザインシステムに準拠する形でUIを再構築していきました。 楽楽販売では、特有のコンポーネントが必要な場面はデザイナーと相談しながら詰めていきました。 プロジェクトはチームで分担し、複数のフェーズに分けて進めました。 フェーズ1とフェーズ2の二段階に分かれており、それぞれ性質の異なる画面群を対象にしています。 フェーズ1: AIに任せられない領域 フェーズ1の対象は一般ユーザ向け画面です。 お客様が日常的に操作する、楽楽販売の中心的な画面群です。 このフェーズでは、56画面を約1年かけて対応しました。 想定以上に時間がかかったのは、 対象の画面の作りが非常に複雑だった からです。 長年運用されてきた楽楽販売のコア画面は、既存のデザインやJavaScriptが複雑に絡み合っており、一つ手を入れると別の部分が壊れる(いわゆるデグレが発生する)リスクが常にありました。 UI統一とはいえ、見た目だけを揃えれば良いわけではなく、既存の挙動を維持しながら慎重に改修を進める必要があったのです。 このフェーズで、私たちはAIによる自動実装をほぼ使いませんでした。 理由は単純で、 自動化に任せると既存実装を壊すリスクが大きすぎたから です。 画面ごとに個々の微妙な事情があり、汎用的なルールで一律に変換できる作業ではありませんでした。 人間が一つひとつのコードを丁寧に読み解き、責任を持って実装する。それがフェーズ1で必要なことでした。 このフェーズで得たのは、「 AIに任せられない領域が確かにある 」という現場の体感でした。 この感覚が、次のフェーズでの判断に繋がっていきます。 フェーズ2: 規模がもたらした新たな課題 フェーズ2の対象は設定系画面です。 管理者設定やDB設定など、お客様の日常操作からは少し離れた位置にある画面群です。 フェーズ1とフェーズ2の実績を、下の表で対比してみます。 フェーズ1(一般ユーザ向け画面) フェーズ2(設定系画面) 画面数 56 350 開発期間 約1年 約半年 AI活用 なし Cursor Rulesによるセルフチェック 画面数が約6倍に増えたにもかかわらず、開発期間は半分に収まっている ——この点にご注目ください。 ただ、これはAI活用だけによる結果ではありません。 対象画面の性質や実装ルールの明確さといった要因が大きく、後述するAIの役割はそのうちの品質担保を支えた一要素にすぎません。 両フェーズの作業の性質の違いが、この差に表れています。 フェーズ1が、複雑な画面ゆえに何度も手戻りを繰り返す作業だったのに対し、フェーズ2は、設定系画面の比較的シンプルな作りに加え、明確な実装ルールがあったことで、基本的に一画面の対応を一度で完結させられました。 フェーズ1ほど手戻りが発生せず、安定したペースで進められたのです。 フェーズ2では進め方も変えました。 350画面を半年で完遂するため、 チームで手分けして大量の画面を並列に実装していく 形に切り替えたのです。 ここで生まれたのが、新たな課題でした。 大量の並列実装を、どうやって品質を担保しながら捌くか 。 実装そのものは機械的な作業なので、進めること自体は可能です。問題はその後のレビューでした。 350画面分のレビュー依頼が次々と上がってくる中で、レビュアーが毎回「アイコンが置換されているか」「不要なクラスが消えているか」「パンくず構造が揃っているか」を目視で確認していくのは、現実的ではありません。 一方で、レビューで本当に確認したいのは、 UI崩れが起きていないか、特殊ケースで挙動が壊れないか、ユーザ体験として問題ないか といった、人間の判断が必要な部分です。 ルール遵守の機械的なチェックに時間を取られ、肝心の「人間の判断が必要な部分」に目がいかない。 これが、作業規模の拡大によって向き合うことになった課題でした。 なお、フェーズ2の実装を機械的に行えるようにするため、私たちは事前にチーム内で詳細な実装ルールを整理していました。 「z-indexの削除」「特定のCSSクラスから別のクラスへの置換」「 <i class="fa ..."> 形式のアイコンから <span class="material-symbols-rounded"> 形式への置換」など、変換パターンが網羅的にドキュメント化されていたのです。 このドキュメントの存在が、次に紹介するAI活用の前提条件になりました。 AI活用の勘所: 実装ルールをAIに翻訳する なぜ「セルフチェック」だったか 私たちがAIを投入した先は、 実装そのものではなく、実装ルールに沿っているかのセルフチェック でした。 実装そのものをAIに任せる選択肢もありました。 ただ、フェーズ1で痛感したように、AIに任せると壊れる領域があります。 フェーズ2の画面は比較的シンプルとはいえ、リスクがゼロというわけではありません。 だからこそ、実装は引き続き人間が責任を持って行い、AIにはチェックを支援してもらう。 この役割分担が、フェーズ2の作業の性質に合っていた のです。 セルフチェックを支援する仕組みがあれば、実装者自身が手元で「ルールに沿っているか」を確認できます。 レビュー依頼が来る段階では、ルール遵守の観点でのチェックが一通り済んでいる状態になる。 レビュアーは、 人間でなければ判断できない部分 にレビューの労力を集中させられるようになります。 Cursor Rulesという仕組み 当時、楽楽販売開発チームではAIコードエディタとしてCursorを採用していました。 Cursorには「Rules」という機能があり、プロジェクトのルートディレクトリに特定の形式でルールファイルを置いておくと、AIが回答を生成する際にそのルールを常に参照してくれます。 このRules機能に、先ほどの実装ルールを記述しました。日本語で書かれた実装ルールを、AIが扱える形のルールファイルに整形する作業です。 完成したファイルは、変換パターンが before / after の具体例つきで章立てされたものでした。下記のような構造です。 ## 不要なアイコン要素の削除 - 不要なアイコンは削除しなければならない - サンプル - before: (元のHTML) - after: (修正後のHTML) 観点のカテゴリとしては、以下のようなものがありました(具体的なクラス名やタグ名は伏せています)。 不要な装飾要素の削除ルール アイコン体系の置換ルール パンくず構造の修正ルール メッセージ表示パターンの置換ルール ページネーション構造の置換ルール パネル構造の追加・調整ルール JavaScript関数名の置換ルール 実装者は改修作業を終えた後、AIに「このルールに沿っているか確認してください」と依頼します。 すると、変更されたコードがルールに照らしてチェックされ、不足や誤りがある箇所を指摘してくれます。 これがフェーズ2の運用の中核でした。 ここで「決まったルールに沿っているかの確認なら、LinterやFormatterのような静的解析ツールで十分では？」と思われるかもしれません。 実際、不要なクラスの削除のような単純な置換であれば、その通りです。 ただ今回のルールには、パンくずやパネルの構造変更、メッセージ表示パターンの置換など、 HTMLの文脈や画面全体の構成を踏まえないと正しく判定できない観点 が多く含まれていました。 「どの位置にどの要素を足すべきか」は画面ごとに事情が異なり、機械的なパターンマッチだけでは拾いきれません。 変更内容の意味を汲んで柔軟に判断してもらえる点が、LLMにチェックを任せた理由でした。 ちなみに、現在ではチームのメインツールはVSCode + Claude Codeに移っています。 ツールは流動的に変わっていきますが、 プロジェクト固有のルールをAIに与えるという考え方は、ツールが変わっても通用する普遍的なアプローチ だと感じています。 運用してみての手応え 正直に申し上げますと、このAI活用によって「具体的に〇時間短縮された」「レビュー工数が〇パーセント減った」といった定量データは、私たちの手元にはありません。 それでも、現場での体感としていくつかの手応えがありました。 ひとつは、 人間の目視という不確定要素が減ったこと です。 実装ルールが大量にあると、人間がレビューで全てを抜け漏れなくチェックするのは難しい。 AIによる事前チェックが入ることで、この見落としリスクが大きく下がりました。 実際、フェーズ2全体を通じて、手戻りは少なかったという体感があります。 そしてもうひとつ、 人間でなければ気づけないところに力を割けたこと です。 ルール遵守のチェックをAIに任せられた分、レビュアーである私たちは「この画面の使い勝手はこれで本当に良いのか」「特殊なケースで挙動が崩れないか」といった、人間の判断が必要な観点に集中できるようになりました。 結果として、350画面の改修を約半年で完遂できました。 これはAI活用だけによるものではなく、対象画面の性質や並列開発しやすい構造、事前のルール整備など複数の要因が重なった結果です。 物量だけ見れば、フェーズ1のペースのまま単純計算すると何年もかかる規模です。 AIにセルフチェックを任せ、人間が本質的なレビューに集中できる体制を作れたことが、この規模を半年で進める支えになりました。 正直に言えば、大量の画面をさばき続ける作業は、地道でなかなか骨が折れるものでした。 それでも、無事に完遂できたときの安堵と達成感は大きかったです！ 振り返って見えたパターン プロジェクトを終えてから振り返ると、いくつか一般化できそうな学びが見えてきました。 作業の性質とAI活用の相性 フェーズ1とフェーズ2の対比からは、 作業の性質によってAIの勘所が変わる ことがはっきり見えました。 複雑で固有性が高い作業は人間が向き合う方が結果的に効率が良く、機械的でルール化でき量も多い作業はAI支援の効果が出やすい。 ただ、この見極めは机上では難しく、 現場で手を動かして得られる感覚 だと思います。 フェーズ1で複雑な画面と格闘したからこそ、フェーズ2でAIを投入する判断ができたのです。 AI活用は、人間の作業との連携で成立する もう一つ、振り返って気づいたことがあります。 「AI活用」は単独のアクションではなく、人間の作業と組み合わさったワークフロー全体である 、ということです。 今回のプロジェクトを工程ごとに分解してみると、こうなります。 実装ルールを決める(人間の作業) ルールをAIが扱える形に翻訳する(人間の作業) AIによるセルフチェック実行(AIの作業) 人間でなければ気づけない部分に集中してレビュー(人間の作業) このうち、純粋に「AIの仕事」と呼べるのは3だけです。それ以外は全て人間が行っています。 それでも、3を組み込むことで全体の効率と品質が大きく変わる。 特に2の「翻訳作業」は肝になる工程でした。AIが解釈しやすい構造に整え、具体例を添え、抜け漏れなく記述する。 今回うまくいったのは、AIが優秀だったからではなく、AIが判断できる形までルールを整えたから だと感じています。 少なくとも今回のケースでは、成否を分けたのはモデルの性能そのものよりも、「AIに何を、どう渡すか」という設計の方でした。 渡す側でどれだけ作り込めるかは、これからのAI活用でも軽視できないポイントだと思います。 そう考えると、今回行ったことは「AIに仕事を任せた」というより、 AIが得意な領域へ仕事を再分配した 、と言うのが近い気がします。 大量のルールを機械的に適用していくところはAIへ。 ルールを定義すること、ルール化できない例外を判断すること、最終的な品質に責任を持つことは、引き続き人間へ。 私たちがAIに任せたのは「セルフチェック」だった——その一点に、この再分配の線引きが表れています。 おわりに 楽楽販売開発チームが楽楽シリーズUI統一プロジェクトで実践したAI活用について、なるべく等身大にお伝えしてきました。 派手な成果や劇的なBefore/Afterはない記事だったかもしれません。 それでも、こうした地に足のついた判断の積み重ねこそが、AIネイティブな開発組織の実像なのだと思っています。 ツールはこれからも変わっていくでしょうが、 AIをどこに使うかを考え続けること 、その姿勢は変わらないはずです。 本記事が、同じように現場でAIと向き合う開発者の方々の参考になれば嬉しいです。 最後までお読みいただき、ありがとうございました。

はじめに 登壇資料 登壇内容 発表の背景 なぜ全部自動化しなかったのか 作成したCLIの概要 半自動設計のポイント 細かいTips LLMに渡す範囲を狭くする 読み取りを自作ツールで行う ツールを絞る Claude Code標準プロンプトは必要な場所だけ使う 登壇してみて まとめ はじめに こんにちは！ エンジニア４年目のTKDです！ 今回は、2026年5月12日に開催されたClaude Code Meetup Japan #5で「Claude Agent SDKを活用した脆弱性調査自動化」というタイトルで登壇してきたので、その内容を紹介します。 この記事は、LLMを使った業務効率化に興味がある方や、セキュリティ運用の自動化で悩んでいる方に向けた記事です。 今回の発表では、脆弱性調査において、調査やレポート作成をLLMに任せる半自動化について話しました。 このようなLLMを利用した取り組みで、定常業務に割く工数を減らすことで、より本質的な課題に取り組める時間を増やし迅速にプロダクトの価値を顧客に届ける状態を目指しました。 登壇資料 登壇資料はこちらです。 Claude Agent SDKによる脆弱性調査 by @7328957 登壇内容 今回の発表では、Claude Agent SDKを使って脆弱性調査を半自動化した取り組みについて紹介しました。 主に以下の内容について話しました。 手作業で行っていた脆弱性棚卸しの流れ Claude Agent SDKを使ったCLIの構成 半自動化するときの判断ポイント LLMを安全かつ安く扱うためのTips 先に結論を述べると、AIに全部任せなくても十分役に立つという話です。 APIの制約や安全性から面倒で曖昧な調査をAIに任せ、管理ツールへの最終記入や判断は人間側に残す形にしました。 発表の背景 普段の脆弱性棚卸しでは、いろいろなツールや画面を行き来する必要がありました。 手作業では、ざっくり以下のような流れになります。 yamoryからSlackに脆弱性通知が届く yamoryをブラウザで開いて未対応項目の詳細を確認する エディタとClaude Codeで対象コードベースで使っているか調べる 影響と対応方針を考える GitHub Discussionsに脆弱性詳細や影響調査内容を書き、対象サービスのラベルを付ける yamoryに調査内容、対応期限、対応方針を書いてステータスを変更する 毎回同じような確認も多いですが、逐一調査対象のコードや外部情報も見に行く必要があります。 そこで、調査と調査レポート作成の部分をClaude Agent SDKで自動化できないか試しました。 なぜ全部自動化しなかったのか 今回は、検知から投稿までをすべて自動化するのではなく、CLIで実行できる半自動の形にしました。 理由は主に以下です。 脆弱性自体の危険度はyamoryのSlack通知で確認できる 緊急対応か定常業務内での対応かは、人間が一目で振り分けられる yamoryのAPIがReadのみで、Writeに対応していない 担当者のローカル実行にすることで、Claudeのサブスクプランを使える 個人的には、こういった対応を間違えるとまずい業務では、いきなりE2Eの全自動を目指さなくてもよいと思っています。 今回はAPIの制約や安全性を総合的に考えて半自動にしました。 実際の感じからも、手動実行できるCLIレベルでも十分便利でした。 作成したCLIの概要 今回作成したCLIでは、ざっくり以下の流れで処理しています。 yamory APIから、期間やステータスで絞り込んだ脆弱性一覧を取得する 既存のGitHub Discussionsタイトルを確認する CREATE / COMMENT / SKIP の処理判定を行う Claude Agent SDKでコード調査、草案作成、ラベル付けを行う 調査結果とyamory記入例をGitHub Discussionsへ投稿する 必要に応じてSlackに通知する このCLIによって、体感では1件あたり5分から10分ほどかかっていた作業が、 バックグラウンド処理込みで体感約2分程度で進められるようになりました。 半自動設計のポイント 今回意識したのは、決定論的に処理できる部分と、LLMに任せる部分を分けることです。 コードで記述している部分は以下です。 yamoryからの一覧取得、検索、詳細取得 既存Discussion検索によるCREATE / COMMENT / SKIP判定 安全性ガードレール GitHub Discussionsへの投稿 一方で、LLMが担当している部分は以下です。 CVE、PoC、修正済みバージョンなどの外部情報調査 現環境での悪用可能性や影響評価 推奨対応方針の下書き Discussionへのラベル付け 判断材料を集めるところはAIに寄せつつ、判断を間違えると危険な部分は人間が確認するようにしました。 この線引きをしておくと、他のLLMを必要とする業務にも応用しやすいと思います。 細かいTips LLMに渡す範囲を狭くする まず、LLMに何でも渡さないようにしました。 期間や状態の絞り込み、重複判定、冪等性、共有ON/OFFのような部分はコードで固定しています。 LLMには、利用状況の調査、影響評価の下書き、推奨対応方針の下書き、記入例の作成を任せました。 これにより、お得で安全にLLMを扱いやすくなります。 読み取りを自作ツールで行う 次に、対象リポジトリの読み取りは自作ツールで行うようにしました。 自作ツールでは、read onlyにしたうえで、ファイルサイズ、拡張子、ファイルパスを解析的に検査しています。 repo外のファイル、secret、巨大ファイル、バイナリなどを拒否することで、安全性を確保しています。 Claude Agent SDKでは、 @tool アノテーションでツール化できるので、このあたりも実装しやすかったです。 ツールを絞る Claude Agentに渡すツールも絞りました。 脆弱性調査では、WebSearchと読み取り専用のrepo検索、repoファイル読み取りツールだけを許可しています。 読み取りを自作ツール以外からできないようにすることで、意図しないアクセスを防ぎやすくしました。 Claude Code標準プロンプトは必要な場所だけ使う Claude Codeの標準プロンプトは、コード探索のようにClaude Codeのハーネスとしての強みがほしい場所だけで使いました。 たとえば、脆弱性調査ではClaude Code標準プロンプトに脆弱性調査用の追加指示を加えています。 一方で、GitHubのラベル付けのような小さい判定では、候補ラベルから選ぶ小さな構造化タスクとしてAgentを分けました。 広い調査と小さい判定でAgentを分けるのは、個人的に扱いやすい設計だと思っています。 登壇してみて 今回登壇してみて、想像以上に多くの方の前で発表することになり非常に緊張する発表でした！ また、作るときは壁打ちや制約で自然に半自動になったのですが、発表資料を作る中で、全自動化を目指すのではなく、人間とコードとLLMで役割を分けることの重要性を改めて考える機会になりました。 まとめ 今回は、Claude Code Meetup Japan #5で「Claude Agent SDKを活用した脆弱性調査自動化」について登壇した内容を紹介しました。 今回紹介した流れは、脆弱性調査以外にも使えると思っています。 明日から使えるポイントとしては、以下の3つです。 無理にE2Eの全自動にせず、半自動を狙う LLMが得意とする情報集めや例文作成をメインに使う 最終記入、冪等性、確認導線は人間とコードで設計する 興味がある方は、ぜひ参考にしてみてください！ ここまで読んでいただきありがとうございました！

はじめに JJUG CCCとは 登壇スライド 外部発信のモチベーション 登壇を通じて得られた気付き 振り返り はじめに 登壇直前に地元バスケクラブが準優勝し、かなりのダメージを負っていた楽楽債権管理チームの冨澤です。 2026年5月30日に行われたJJUG CCC 2026 Springで初登壇してきました。 本記事は、そのレポートとなります。 JJUG CCCとは JJUG CCCは、日本最大のJavaコミュニティイベントです。 日本Javaユーザグループ（JJUG） / Japan Java User Group (JJUG) が主催しており、今回は春に開催されたカンファレンスです。 （秋にもあります！2026年11月28日開催予定） ccc2026spring.java-users.jp 登壇スライド speakerdeck.com 外部発信のモチベーション なぜCIを速くしたいかは登壇スライドに書いているので、なぜ外部発信をしたのかについて少し書いておこうと思います。 1つ目は、取り組みを始めた当時、自分が調べた範囲ではJava関連プロダクトのCI時間削減の記事が少なかったからです。 RailsやGo、フロントエンド関連のCI時間削減の記事は多かったのですが、Java関連の記事はあまり見つかりませんでした。 そのため、成功でも失敗でも何かしら貢献ができるのではないかと考え、最初の取り組みを以下のテックブログに書きました。 tech-blog.rakus.co.jp ちなみにこのやり方は、Goのテスト実行における「パッケージ単位で実行を分け、パッケージ内のテストは必要に応じて t.Parallel() で並列化する」という考え方から着想を得ました。 2つ目は、外部からのフィードバックを得たかったからです。 これは今回JJUG CCCに登壇したかった理由でもあります。発表後や懇親会の場で社外の方とお話しする中で、新しいフィードバックや気付きを得られたらよいなと考えていました。 こうした機会は自分から動かないと得られないと思い、CfPを提出しました。 また、上記のテックブログの内容からさらに改善を行ったので、その取り組みも紹介したいと考えていました。 登壇を通じて得られた気付き 何名かの方とお話しする中で、共通して話題に挙がったのが「PRごとに毎回すべての単体テストを実行しているのか？」という点でした。 これは本当におっしゃるとおりで、今回の取り組みでCI時間を約50％削減できたものの、それでもまだテスト実行に約10分かかっています。 デグレの早期検知や安心材料としてすべての単体テストを実行しているのか、もっと速くできないか、すべて実行する必要は本当にあるのか。そうした会話を通じて、「そもそも何のためにこれをやっているのか？」という重要な問いに何度か立ち返ることができました。 自分たちのプロダクトにとって本当に大事なことは何か。逆に、何をトレードオフとして選ばないのか、あるいは優先度を下げられるのか。そうした視点の重要性に改めて気付くことができました。 例えば、より速くPRをマージしたいのであれば、変更の影響範囲に絞ってテストを実行し、夜間にすべてのテストを実行するという選択肢があります。逆に、速さよりもデグレの早期検知を重視するのであれば、毎回のPRですべてのテストを実行する判断になるかもしれません。 目の前の作業だけに没頭するのではなく、時折立ち止まって目的を見直す姿勢が大事なのだと改めて感じました。 振り返り CfP採択の結果連絡が来た時は、非常に嬉しかったです。 採択されたことが信じられず、社内の方にも本当に採択されたのか確認を取ったほどでした。 登壇直前までかなりバタバタしており、とても緊張していましたが、何名かの同僚が来てくれており非常に心強かったです。 登壇直後、次に発表される方からの質問や廊下での立ち話、懇親会での会話など、様々な場面で社外の方と交流することができました。「E2EやAPIテストなど他のテストとの役割分担はどうしてる？」「コーディングエージェントにテストをうまく書かせる工夫は？」「開発組織で取り組んでいる工夫は？」など、話題は多岐にわたり、どれもとても楽しい時間でした。 当初の想定どおり、たくさんの方と交流でき、そこで得たものを今後の業務に活かしていきたいと思います。 今後もこうした登壇の機会があれば、ぜひ続けていきたいです。 登壇者・参加者・企画・運営の皆さま、素敵な場をつくっていただき本当にありがとうございました！

はじめに 給与計算オプションの開発で最初に困ったこと なぜ開発部だけでなく事業部にも給与計算の知識が必要だったのか まず、初心者向けの課題図書を選んだ MVP開発に必要な知識に絞って、学習コンテンツを作った 仕様説明では、「なぜその機能が必要なのか」まで説明した リリースまで進めるうえで大事だったこと 1. 自分だけが詳しい状態にしない 2. 開発部・事業部が必要な知識を持てるようにする 3. すべてを学ぶのではなく、今回必要な範囲に絞る 4. 仕様の背景や目的まで伝える まとめ はじめに 楽楽勤怠のプロダクトマネジメントをしている @k0First です。 2026年4月に、楽楽勤怠から給与計算オプションをリリースしました。 www.rakus.co.jp 給与計算オプションの開発で難しかったことの一つが、給与計算というドメインの理解でした。 私は前職で給与計算システムの開発経験があり、一定のドメイン知識を持っていました。 一方で、今回の開発では、自分以外の開発部・事業部メンバーの多くが、給与計算の知識をほとんど持っていない状態からのスタートでした。 給与計算は、勤怠データや賃金規定、各種手当、控除、割増計算、端数処理など、さまざまな要素が絡み合う複雑なドメインです。 しかも、最終的に扱うのは「給与」です。 「だいたい合っていそう」では済まされません。 PdM/POである自分だけが理解していればよい、というものではありませんでした。 開発部が仕様の背景を理解して設計・実装できること。 事業部がリリースに向けた説明やマニュアル作成を進められること。 そのためには、関係者がそれぞれの役割に必要な範囲で、給与計算を理解している必要がありました。 給与計算オプションは、2025年7月に開発を開始し、2026年4月にリリースしました。 この期間でリリースまで進められた理由の一つは、早い段階から開発部・事業部のドメイン知識を底上げし、関係者が自分の役割の中で判断しやすい状態を作れたことだと思っています。 この記事では、給与計算を知らないメンバーと給与計算オプションをリリースするために、どのようにドメイン知識を身につけてもらったのかを書いていきます。 給与計算オプションの開発で最初に困ったこと 給与計算オプションの開発で最初にぶつかった壁は、給与計算というドメインそのものの難しさです。 給与計算は、単に勤怠時間を集計して金額を出せば終わり、というものではありません。 会社ごとの賃金規定に基づいて、基本給、各種手当、控除、割増賃金、端数処理などを組み合わせて計算します。 さらに、会社によってルールや運用が異なります。 ある会社では当たり前の計算方法が、別の会社ではまったく違う。 そんなことも普通に起こります。 つまり、給与計算オプションを作るには、画面や機能の仕様を理解するだけでは足りません。 その裏側にある業務や、 「なぜその計算が必要なのか」 まで理解する必要があります。 私は前職で給与計算システムの開発経験があったため、ある程度の前提知識を持っていました。 しかし、自分以外の開発部・事業部メンバーは、給与計算の知識がほとんどない状態です。 このまま開発を進めると、何が起きるか。 開発部からは、こんな確認が出てきます。 この項目はなぜ必要なのか この計算ルールはどの業務に使われるのか この仕様で、どこまでのケースに対応できるのか こうした質問に答えること自体は、PdM/POの大事な役割です。 ただ、すべての確認や判断が自分に集まる状態になると、開発のスピードが落ちてしまいます。 さらに、リリースに向けた説明やマニュアル作成を進めるときにも、毎回自分が説明しないと前に進まない状態になってしまいます。 ここで最初に考えたのは、 「自分がもっと詳しく説明できるようにしよう」 ではありませんでした。 それよりも、 みんなが自分の役割に必要な範囲で、給与計算を理解できる状態を作らないといけない ということでした。 給与計算オプションをリリースまで進めるためには、自分だけが詳しい状態から抜け出す必要がありました。 なぜ開発部だけでなく事業部にも給与計算の知識が必要だったのか 最初は、開発部のメンバーに給与計算の知識を身につけてもらうことが重要だと考えていました。 開発部が仕様の背景を理解していないと、設計や実装の判断が難しくなります。 例えば、以下のような判断です。 ある計算ルールをどう表現するか どこまで設定で変更できるようにするか どのような条件でエラーを返すべきか こうした判断は、仕様書に書かれている内容だけでは決めきれません。 給与計算の業務背景を理解しているからこそ、判断できることがあります。 ただ、開発を進める中で気づきました。 「あれ、これは開発部だけの話じゃないぞ・・・？」 今回の開発では、事業部もリリースに向けて重要な役割を担っていました。 例えば、マニュアル作成です。 操作手順だけを書けばよいなら、画面を見ればある程度進められるかもしれません。 でも実際には、それだけでは足りません。 なぜこの設定が必要なのか この項目を設定すると、どの計算に影響するのか お客様はどの場面でこの機能を使うのか こうした背景がわからないと、マニュアルの説明も薄くなってしまいます。 お客様にリリース内容を説明する場合も同じです。 今回の給与計算オプションで何ができるのか。 どのような業務を支援する機能なのか。 どこまでが対象で、どこから先は対象外なのか。 これらを説明するには、事業部側にも給与計算の基本的な理解が必要でした。 つまり、給与計算オプションをリリースするには、開発部だけでなく事業部にもドメイン知識が必要だったのです。 開発部が実装を進める。 事業部がお客様に向けた説明やマニュアルを準備する。 そして、リリースに向けてそれぞれの立場で判断していく。 その流れを止めないためには、関係者がそれぞれの役割に必要な範囲で、給与計算を理解している必要がありました。 まず、初心者向けの課題図書を選んだ 最初に取り組んだのは、初心者向けの課題図書を選ぶことです。 給与計算について学べる本はたくさんあります。 ただ、実際に探してみるとけっこう大変でした。 専門的すぎる本もあります。 法律や制度の説明が中心の本もあります。 実務担当者向けに、かなり細かい手続きまで書かれている本もあります。 もちろん、どれも重要な知識です。 ただ、今回の目的は、開発部・事業部のメンバーを給与計算の専門家にすることではありません。 必要だったのは、給与計算の基本的な考え方を理解し、仕様やリリース内容を理解できるようになることです。 そこで、本屋や図書館に行き、実際に本を手に取って選びました。 このとき見ていたポイントは、主に次のようなものです。 給与計算の全体像がつかみやすいか 初心者でも読み進めやすいか 専門用語が多すぎないか 実務の流れをイメージしやすいか 開発部・事業部のどちらが読んでも役立ちそうか いくつか本を見比べながら、「最初に読むならこれがよさそうだな」という本を選びました。 ここは、思った以上に大事な工程でした。 最初に触れる情報が難しすぎると、 「給与計算ってよくわからない」「自分には関係なさそう」 と感じてしまいます。 逆に、最初の一冊で全体像がつかめると、その後の仕様説明や議論がかなり進めやすくなります。 選んだ本は、開発部・事業部共通の課題図書として指定し、事前に読んでもらいました。 ただ、いきなり課題図書を読んでもらうだけでは、少しハードルが高いとも感じていました。 給与計算をまったく知らない状態だと、本を読み始めても、最初の用語や業務の流れでつまずく可能性があります。 そこで、超初心者向けに 給与計算の超概略資料 も作成しました。 この資料では、細かい制度や計算方法には踏み込みすぎず、まずは以下のような全体像をつかめるようにしました。 給与計算とは何をする業務なのか 勤怠情報と給与計算がどうつながるのか 支給、控除、割増といった基本的な考え方 賃金規定が給与計算にどう関係するのか まずは概略資料でざっくり全体像をつかむ。 そのうえで課題図書を読む。 この流れにすることで、学習のハードルを下げることを意識しました。 課題図書を共通にしたのは、全員に同じレベルの知識を求めたかったからではありません。 まずは、 「給与計算ってこういうものなんだ」 という感覚を持ってもらいたかったからです。 例えば、「賃金規定」「割増賃金」「控除」「支給項目」といった言葉を聞いたときに、まったくイメージが湧かない状態と、なんとなくでも意味がわかる状態では、その後の理解度が大きく変わります。 まずは、給与計算の世界に入るための入口を作る。 課題図書と超概略資料には、そんな役割を持たせていました。 MVP開発に必要な知識に絞って、学習コンテンツを作った 課題図書を読んでもらうことで、給与計算の基本的な考え方に触れてもらうことはできました。 ただ、 一度読んだだけで身につくものでもありません。 給与計算の範囲はとても広いです。 全部をちゃんと学ぼうとすると、本当に終わりが見えません。 一方で、開発は前に進めなければなりません。 全員が給与計算のすべてを理解するまで待っていたら、開発速度が落ちてしまいます。 そこで考えたのが、 今回のMVP開発に本当に必要な知識を、まず最初に身につけてもらう ということでした。 必要だったのは、給与計算のすべてを理解してもらうことではありません。 給与計算オプションのMVP開発に必要な知識 仕様を理解し、判断するために必要な知識 リリースに向けた説明やマニュアル作成に必要な知識 この範囲に絞って、学習コンテンツを作成しました。 ここで大事にした狙いは、主に2つあります。 1つ目は、 本当に必要な知識から先に身につけてもらうこと です。 給与計算の知識をすべて網羅しようとすると、どうしても時間がかかります。 もちろん深い理解は大事ですが、今回まず必要だったのは、開発やリリース準備を進めるための最低限の理解でした。 そのため、MVP開発に関係する内容を中心に整理し、優先的に学べるようにしました。 2つ目は、 本を読むだけではなく、別の形で復習できるようにすること です。 本を読んだだけだと、どうしても理解が曖昧なまま残る部分があります。 一度読んで「わかった気がする」と思っても、仕様説明や実際の議論の場になると、うまく結びつかないこともあります。 そこで、読むだけではなく、聞いたり、確認したりできる形にすることで、理解度を高められるようにしました。 この学習コンテンツ作成に活用したのが、Google NotebookLMです。 具体的には、自分で整理した内容や、業務上扱える情報をもとに、音声解説や理解度確認テストの作成に活用しました。 Google NotebookLMを使ってよかったのは、知識を 「読むもの」だけでなく、「聞けるもの」「確認できるもの」 に変えられたことです。 音声解説では、給与計算の基本的な考え方や、今回の給与計算オプションで扱う範囲について、初心者でも理解しやすいように説明をチューニングしました。 理解度確認テストでは、ただ読んだり聞いたりするだけではなく、自分がどこまで理解できているかを確認できるようにしました。 ここで特に気をつけたのは、説明の粒度です。 給与計算に詳しい人向けなら、専門用語を使えば短く説明できます。 でも、今回の対象は給与計算をほとんど知らないメンバーです。 いきなり専門用語から入ると、そこで止まってしまいます。 そのため、 なぜその考え方が必要なのか どんな業務に関係するのか 今回の仕様ではどこに関わるのか という流れで理解できるようにしました。 また、あえて説明しすぎないことも意識しました。 給与計算のすべてを詰め込むと、情報量が多すぎて、かえって大事なことが見えにくくなります。 今回は、MVP開発に必要な知識に絞る。 その範囲ではしっかり理解できるようにする。 この割り切りが、かなり重要だったと思います。 「給与計算を全部学ぶ」のではなく、「今回の開発を前に進めるために必要な知識を身につける」。 この目的をはっきりさせたことで、学習コンテンツの方向性も定まりました。 仕様説明では、「なぜその機能が必要なのか」まで説明した ドメイン知識を身につけてもらう取り組みと並行して、仕様説明のやり方も変えました。 給与計算オプションの仕様は、画面や機能だけを見るとかなり複雑です。 入力項目も多く、設定する内容も多岐にわたります。 そのため、「この画面ではこの項目を設定します」という説明だけでは、なかなか理解しきれません。 むしろ大事なのは、その先です。 なぜこの画面が必要なのか なぜこの設定項目が必要なのか この機能は、どの給与計算業務を支えるものなのか MVPではどこまで対応し、どこから先は対象外にするのか ここまで説明して、ようやく仕様が立体的に見えてきます。 例えば、ある設定項目を説明するときも、単に「ここに値を入力します」とは言いません。 この項目は、こういう賃金規定を表現するために必要です この設定によって、この計算結果が変わります 今回のMVPでは、まずこの範囲に対応します というように、業務上の意味や判断の背景をセットで伝えるようにしました。 すると、少しずつ会話の質が変わっていきました。 単なる仕様確認だけではなく、 このケースも考慮したほうがよさそう この表現だと、お客様には伝わりにくいかも ここはMVPでは割り切ってもよさそう といった会話が出るようになってきました。 これは、とても大きな変化でした。 自分が一方的に説明し続けるのではなく、開発部・事業部がそれぞれの視点で考え、判断しようとしてくれる。 その状態に近づいていったことで、開発もリリース準備も進めやすくなりました。 仕様を伝えるだけでは足りません。 特に複雑なドメインでは、 「なぜその仕様なのか」 まで伝えることが大事だと改めて感じました。 リリースまで進めるうえで大事だったこと 今回の開発を振り返ると、リリースまで進めるうえで大事だったことは、大きく4つあります。 1. 自分だけが詳しい状態にしない PdM/POがドメイン知識を持っていることは重要です。 ただ、それだけでは開発は進みません。 特に給与計算のような複雑なドメインでは、開発部・事業部がそれぞれの役割の中で判断できる状態を作る必要があります。 2. 開発部・事業部が必要な知識を持てるようにする 開発部には、仕様の背景を理解したうえで設計・実装するための知識が必要です。 事業部には、顧客説明やマニュアル作成を進めるための知識が必要です。 役割は違っても、リリースに向かううえで必要な知識は重なります。 3. すべてを学ぶのではなく、今回必要な範囲に絞る 給与計算の知識は本当に広いです。 全部理解してから進めようとすると、かなり時間がかかります。 だからこそ、今回のMVP開発に必要な知識に絞りました。 概略資料で全体像をつかみ、課題図書で基本を押さえ、学習コンテンツで今回必要な知識を補う。 この進め方は、現実的で効果的だったと思います。 4. 仕様の背景や目的まで伝える 仕様書や画面だけでは、なぜその機能が必要なのかまでは伝わりにくいです。 その機能がどの業務課題を解決するのか。 なぜその項目が必要なのか。 どこまでをMVPで扱うのか。 こうした背景や目的を説明することで、関係者が自分の役割の中で判断しやすくなります。 振り返ると、今回の開発では「仕様を作ること」だけでなく、 「理解できる状態を作ること」 にかなり時間を使いました。 最初は遠回りに見えるかもしれません。 でも、複雑なドメインでは、この遠回りが結果的に近道になることがあります。 関係者が理解し、自分の役割で判断できるようになると、開発やリリース準備が止まりにくくなるからです。 まとめ 給与計算オプションの開発では、給与計算という複雑なドメインに向き合う必要がありました。 今回あらためて感じたのは、複雑な業務ドメインのプロダクト開発では、PdM/POが詳しいだけでは不十分だということです。 開発部が仕様の背景を理解して設計・実装できること。 事業部がリリースに向けた説明やマニュアル作成を進められること。 そのためには、それぞれの役割に必要な範囲で、ドメイン知識を身につけてもらう必要があります。 課題図書、超概略資料、学習コンテンツ、Google NotebookLMを使った音声解説や理解度確認テストなど、やったことはいくつかあります。 ただ、一番大事だったのは、 自分の中にある知識を、関係者が理解しやすい形に変えて届けること だったと思います。 2025年7月に開発を開始し、2026年4月にリリースまで進められた背景には、こうした取り組みによって、開発部・事業部がそれぞれの役割で動きやすくなったことがありました。 何を作るかを考えることと同じくらい、誰がどこまで理解している状態を作るかも大事。 今回の開発を通じて、そんなことを強く感じました。