今回は、楽楽勤怠に組み込まれたAIチャットボット機能の開発を担当した、楽楽勤怠開発課の黒田さんに話を聞きました。 黒田さんは新卒2年目。事業部・デザイナー・インフラ担当など多くの関係者を巻き込むこの開発を、ほぼ一人で任されています。 楽楽勤怠とは 楽楽勤怠のAIチャットボットとは何か なぜこの機能を作ったのか 開発の話：工夫した点、難しかった点 実装より大変だった、社内の情報連携 当初試していたRAGの課題と方針転換 回答精度のチューニングと、こだわった速さ 今後の展望 おわりに 楽楽勤怠とは 「楽楽勤怠」は勤怠管理・給与計算をラクにするクラウド型の勤怠管理システムです。 楽楽勤怠のAIチャットボットとは何か このAIチャットボットは、よくある質問（QA）に回答する機能です。実際によく寄せられる問い合わせをもとに作られたQAをデータとして持ち、たとえば「有給休暇の設定方法」といった、操作に関する質問にチャットで答えます。過去のやり取りを踏まえて会話を続ける形ではなく、都度の質問に対してその場でQAから最適な回答を探して返す、一問一答形式のシンプルな仕組みです。 なぜこの機能を作ったのか 開発の出発点にあったのは、お客様が楽楽勤怠の操作でわからないことに直面しても、サポートサイトだけでは自己解決できず、結局CSへ問い合わせて回答を待つことになってしまう、という状況でした。 チャットボットであれば、お客様はその場ですぐに回答を得られ、業務を止めずに済みます。この一見シンプルな狙いを形にするまでには、開発の現場でいくつもの工夫と苦労がありました。 開発の話：工夫した点、難しかった点 開発はほぼ一人で担当し、同じチームの先輩にサポートしてもらいながら進めました。期間は2026年4月から6月末のリリースまで、検証を含めておよそ3ヶ月でした。 Google Cloudの知識もゼロ、社内の関係者もまだ多くは知らない状態からのスタートでしたが、それでも今回のプロジェクトでは実装の中心を任せてもらいました。 実装より大変だった、社内の情報連携 正直、実装のタスク自体はそこまで多くありませんでした。それよりも、事業部やデザイナー、インフラ担当、AI開発課など色々な関係者と何度もやり取りをしながら情報を集め、調整していくことの方が大変でした。 チャットボットに投入するQAは事業部が主導して作成しています。サポートサイトに載っている内容をすべて移行したわけではなく、実際によく寄せられていた問い合わせとその回答をもとに、新しくQAのセットを作ってもらいました。私の役割は、そのQAをデータとして仕組みに投入していく部分です。QAの追加・更新はリリース後も続く運用で、事業部が内容を作成し、開発側で個人情報などが含まれていないかをレビューしたうえでインフラ担当が反映する、という体制で回しています。 事業部との連携では、開発者側にしか見えていない考慮点を自分から拾い上げる難しさもありました。チャットボット機能を使えるユーザーの範囲や、権限をどう制御するか、機能を停止する場合にどう対応するかといった仕様上の論点は、事業部側からは見えにくいものです。自分から議題に上げないと見過ごされてしまうので、そこを拾い上げて要件を詰めていくのが大変でした。 今回、事業部とのやり取りでは、スピード感を意識して進めました。他部署とのやり取りでは、きちんとしたドキュメントに書き起こしてから送ろうとしたり、次の定例のアジェンダに入れておけばいいかと連絡を持ち越したりしがちです。ただ、その進め方だと、一度運用が走り出してから認識のズレに気づくことになり、後から直そうとするほど手戻りが大きくなってしまいます。そこで私は、事業部との週1回の定例に加えて、気になった点が出てきたらその場でチャットに書き込み、「ここに書いておいたので」と都度共有するようにしていました。さらに、事業部側で実際に操作して確認できる検証環境もあわせて提供しました。その結果、次の定例まで抱え込むことなく、その都度細かくすり合わせができたので、大きな手戻りを防ぐことができました。 当初試していたRAGの課題と方針転換 チャットボットの基盤にはGoogle CloudのDialogflow CXを採用しています。 最初はGoogle CloudのVertex AI上で、自分たちでRAGの仕組みを実装しようとしたのですが、回答までのスピードが遅く、改善にも時間を要しました。方針転換のきっかけはAI開発課への相談でした。パフォーマンスを改善したいと相談したところ、「業務システム部が同じような仕組みをすでにGoogle Cloud上に構築している」と教えてもらい、その構成を参考にする方針に切り替えました。 Google Cloudの知識がまったくない状態からのスタートだったため、業務システム部に構成や設定を教わりながら、何度もミーティングやチャットでのやり取りを重ねて理解を進めていきました。 インフラチームには、そうして把握した内容をドキュメントにまとめたうえで、本番環境の構築を依頼しました。楽楽勤怠側で実装したのは、画面のスタイル調整と、チャットボット機能を使える権限の制御程度で、ロジックの大部分はGoogle Cloud側に構築し、楽楽勤怠にはそのUIを埋め込む構成になっています。 回答精度のチューニングと、こだわった速さ 精度を検証する中では、うまく回答が見つからないケースも出てきました。その対応として、QA同士に重みを設定したり、「退職者」と「元社員」のような表記ゆれを類義語として登録し、正しく紐づくようにするチューニングが可能な仕組みになっています。このチューニング自体は主に事業部が担当していて、私は設定を行う立場でした。 速さへのこだわりも、事業部からの指摘がきっかけでした。自前で構築していた当初は応答に20秒ほどかかっていましたが、気軽な操作の質問に対してそれだけ待たされるのは体験として良くない、という事業部からの声を受けて、大きく短縮する方針に変わりました。事業部とは今も週1回のミーティングを続けており、気になる点をその都度すり合わせているため、大きな認識のズレが生まれる前に軌道修正できています。 その結果、もともと20秒ほどかかっていた応答速度は、およそ5秒にまで大幅に短縮できました。検索に特化したマネージドサービスであるGoogle CloudのAI Applicationsを使う構成にしたことが、このパフォーマンスに寄与していると考えています。 今後の展望 直近では、AIチャットボットの機能拡充を考えています。 現状はQA情報のみを参照しているため、解決しない場合にお客様ご自身で仕様や操作方法を探す必要があり、認知負荷が高い状態となっています。そこで、サポートサイトに記載されている仕様や操作方法に基づく回答の提供や、該当画面へのリンク表示などを実現したいと考えています。これにより、回答可能な範囲の拡充とお客様の検索負荷の軽減を目指します。 おわりに 今回のAIチャットボットは、お客様がサポートサイトだけでは自己解決できず、CSに問い合わせて回答を待つことになってしまう、という地道な課題を解消するところから始まりました。 新卒2年目の黒田さんが、知らない技術・知らない部署を巻き込みながら形にしたこの一歩は、楽楽勤怠全体のAI機能拡充における最初の足がかりでもあります。基盤選定やデータ作成でも、既存の知見を積極的に取り入れながら、着実に形にしていくプロセスが印象的でした。効果測定など、まだこれからの部分も含めて、今後の展開に注目していきたい機能です。

楽楽メールマーケティング開発課では現在、「AI-HTMLメール生成機能」の開発に取り組んでいます。8月26日には一部のお客様向けにβ版を先行リリースし、12月には全てのお客様へβ版をリリースする予定です。 本記事では、開発を担当する垣内繁直さんに、取り組みの背景や工夫した点、開発を振り返って感じたことをお聞きしました。 楽楽メールマーケティングとは なぜこの機能を作ることになったのか AI-HTMLメール生成機能とは、どんな機能なのか 開発で難しかったことは何か スピードと品質は、どう両立させたのか 今後、どう進化させていきたいのか 楽楽メールマーケティングとは 「楽楽メールマーケティング」はメール作成から配信まで簡単にできるメルマガ配信サービスです。 なぜこの機能を作ることになったのか 楽楽メールマーケティングでは、メールマーケティングの効果を高めるために、月6回程度の配信を推奨しています。しかし実際には、既存顧客の約50%がこの推奨回数を満たせておらず、十分に配信できていない状態が続いていました。 原因を調査したところ、大きく2つの課題があるのではないかと考えました。 1つは配信のための担当者の稼働がそもそも取れないこと、もう1つはどんなメールがお客様に刺さるのかというノウハウが不足していることです。 この2つの課題を解決する手段として着目したのが、AIによるメールの自動生成です。 AIが自動生成することで、メール1通あたりの作成時間を大幅に削減し、稼働不足を解消します。 もう一つの狙いは、既存のノウハウをAIに引き継がせることです。楽楽メールマーケティングにはこれまで多くのお客様の配信を支援してきた実績があり、その中でどのような文章がメールの成果につながりやすいかというノウハウがすでに蓄積されています。このノウハウをAIのメール生成機能に組み込むことで、AI自身が質の高いメール文面を提案できるようにしました。これにより、メールマーケティングの専門知識を持たないお客様でも、成果につながりやすいメールを作成できるようになります。 時間をかけなくても、お客様に質の高いメールを届ける。質とスピードをどちらも向上させることがこの機能の目指すところです。 AI-HTMLメール生成機能とは、どんな機能なのか メールを作成する際は、まず自社の商品・サービスを登録します。ここでは、製品ページや自社サイトのURLを入力するか、PDFファイルを取り込むだけで、AIが情報を取得・分析し、製品情報を自動で作成します。 取り込んだ製品情報をもとに、配信するメールの方針を設定します。配信目的は、アポ獲得やウェビナー集客など、楽楽メールマーケティングがこれまで培ってきた成果実績にもとづくテンプレートから、用途に応じて選択する仕組みです。配信ターゲットはAIが自動で提案し、そのまま使うこともカスタマイズすることもできます。あわせて、メール本文に埋め込む誘導ボタン（CTA）やロゴの挿入位置、署名についても設定します。 方針が固まると、製品情報と方針をもとにAIがメール本文の案を複数生成します。ユーザーが選んだ案は楽楽メールマーケティングに従来から搭載されているリッチなHTMLエディターにそのまま展開され、デザインを追加で編集したうえで配信できる仕組みです。 すでに何社かのお客様が、この機能で作成したメールをそのまま配信できているほど、高い品質に達しています。そのうえで、さらに質の高いメールを届けられるよう、生成品質の向上にも継続して取り組んでいます。 開発で難しかったことは何か 開発で難しかった点は大きく2つあります。1つは開発期間の短さです。この案件は2ヶ月でβ版をリリースするという要望があり、事業部側からも早期リリースへの強い要望がありました。 もう1つは技術的な挑戦です。バックエンドをTypeScriptで実装したこと、AI機能をこのチームで実装するのは初めてだったことなど、実績のない技術への挑戦が続きました。 技術選定には明確な理由があります。AIのモデルにOpenAIのGPTを採用したところ、対応SDKの言語がTypeScriptやGoなどに限られていました。バックエンドチームはこれまでPHPしか扱ったことがありませんでしたが、PHP向けのSDKがなかったため、楽楽自動応対のAI-FAQ機能のバックエンドですでに採用実績のあったTypeScriptを選び、開発効率を重視しました。 開発期間が短い中で、実績のない新しい技術を使って開発することが、最大の難しさでした。 スピードと品質は、どう両立させたのか AI機能そのもの、特にプロンプトの調整や生成物の品質評価は、楽楽メールマーケティング開発課とは別部署のAI開発課が担当しました。楽楽メールマーケティング開発課は、それをアプリケーションに組み込む役割を担いました。この役割分担が、2ヶ月という短期間での開発を可能にした理由の一つです。 組み込みで特に工夫したのはプロンプト周りです。AI開発課が品質を担保したプロンプトを静的ファイルとして切り出し、そのまま使う仕組みにすることで、組み込み時に品質を損なわないようにしました。 開発の進め方自体にも工夫がありました。これまでチームではウォーターフォール的に要件を固めてから開発する進め方が中心でしたが、2ヶ月という期間ではそれが通用しません。要件が固まりきらないまま、開発と設計を同時に走らせました。 スピードを出すためにはAIを活用することが必須でしたが、単純に生成させるだけでは保守性の低いものができてしまいます。 そこでこだわったことが、AIの生成したコードに対する静的解析・リントなどのガードレールです。フックの仕組みを使い、AIがコードを実装するたびにガードレールが自動的に働き、指摘があればAI自身が修正するループを作ることで、人が介入しなくても一定の品質を保てるようにしました。 開発初期の1ヶ月ほどは、AIが出したコードをほぼ全て人間がレビューしていましたが、そこで挙がった指摘を静的解析やリントのルールに落とし込むことで、徐々にレビュー範囲を減らしていきました。この取り組みにより、後半は多くをAIに任せられる状態になりました。 品質を担保しながらAIに任せる範囲を広げていく仕組み作りこそが、今回の開発で最も工夫した点です。 今後、どう進化させていきたいのか 初段リリース以降は、β版利用時のお客様の声をもとに方向性を固めていく方針です。現時点で検討している方向性は、大きく3つあります。 1つ目は、応用的なメールへの対応です。自社テンプレートへの対応や、企業ごとのプロンプト追加に対応することで、これまで「ラクスの標準的な形」に合わせる必要があり対象外だったお客様も含め、より多くのお客様にこの機能を使ってもらえるようにしたいと考えています。自社のブランドガイドラインや既存の運用フローを崩さずに、AI生成のメリットを享受できる状態を目指します。 2つ目は、複数のメールコンテンツと配信セットの提案です。お客様が指定した配信内容に対して複数のメール案を作成・提案し、選ばれた案をそのまま配信セットまで組めるようにします。1通ずつ作成・配信していた業務をまとめて完結できるようにすることで、「次のメールを考える時間がない」という状況を解消し、配信頻度の維持・向上につなげたいと考えています。 3つ目は、過去のメール内容や配信結果を分析した、次に配信すべきコンテンツの自動提案です。配信結果画面と連動し、これまでの配信結果と自社の製品情報をもとに、次に配信すべきコンテンツをAIが提案し、メール作成まで行う機能を目指しています。単発のメール作成支援にとどまらず、配信結果を活かした改善サイクルを、ノウハウがなくても回せるようにすることが狙いです。 3つの方向性に共通するのは、より多くのお客様に、より少ない手間で、成果につながるメールを配信し続けてもらうという狙いです。稼働不足とノウハウ不足という2つの壁を取り除くことから始まったこの機能は、これからも進化を続けていきます。

こんにちは。ラクスのフロントエンド推進課の亀ノ上です。 Webアクセシビリティは、2022年のチームの課題棚卸しで私が挙げたテーマです。その後もR&Dの取り組みとして続けてきましたが、期日のある機能開発と並べると優先順位は後ろになり、着手には至っていませんでした。 今回、エンドユーザー向けの公開画面を持つ機能の開発で、Webアクセシビリティが要件になりました。対応を進める中で作ったのは、Webアクセシビリティを向上させる仕組みではありません。「どこが直せるのかを、プロダクトに手を入れずに知る」ためのレポート作成ツールでした。 この記事は、ツールの設計判断と、AIにどこまで任せられるのかが見えたところまでの記録です。同じようにWebアクセシビリティの向上に着手できずにいる方の判断材料になればと思います！ アクセシビリティが後回しになる構造 取り組みが動き出したきっかけ プロダクトにlintを入れなかった理由 ツールの構成とAIの担当範囲 ルールの絞り込み基準 3リポジトリに回して分かった傾向 AIに改善を頼んで返ってきたコード AIが指摘を消す方向に向かう理由 次の課題はインプットの設計 今回の学びと、これから アクセシビリティが後回しになる構造 まずお伝えしたいこととして、社内で取り組みを提案してこなかったわけでも、提案が否定されたわけでもありません。工数を理由に断られるというより、やるのはいいけど機能開発が優先、となって結局稼働が取れず、未着手のままになる…というのが近い状況でした。 Webアクセシビリティは、「重要だが必須要件ではない」という位置に置かれがちです。期日のある機能開発と並べれば優先度は下がります。その判断自体は自然かもしれませんが、毎期同じ優先度となると、チームは着手しないまま次の期に入ってしまいます。 取り組みが動き出したきっかけ 要件になった機能（ AI-FAQ機能 ）は、エンドユーザー向けの公開画面を持っています。管理画面でコンテンツを作り、それを外部のエンドユーザーに公開します。ラクスのプロダクトの多くはバックオフィス業務を担う管理画面です。そこに、利用者を契約企業の担当者に限定しない公開画面が加わることになります。 Webアクセシビリティが要件になった理由は、どんな環境で使われるか分からない画面で、読み上げに対応していない、キーボードで操作できない、というような状態が、そのまま「使えない人がいる」ことにつながるからです。 要件になれば、最初にやることは現状の確認です。どの画面のどこが基準を満たしていないのかが分からなければ、直す範囲も、かかる工数も見積もれません。 注意すべき点として、Webアクセシビリティの確認はすべて自動チェックに任せられるわけではありません。自動チェックで検出できるのは一部で、残りは実際の画面を操作しながら確かめることになります。 自動チェックで分かる部分に関しては、プロダクトが違っても同じ調べ方が通用することがあります。今回の取り組みでは、その部分だけを切り出して、担当プロダクト専用にしない形で作りました。フロントエンド推進課としても、各プロダクトがWebアクセシビリティをどこまで満たしているのかを一覧で把握したいというニーズがあったためです。 作成するにあたって、プロダクトに導入するのではなく、シンプルに知るためのツールにしたい...そう考えました。プロダクトに組み込むのではなく、静的解析を社内で決めた基準に合わせて横断的に回せるようにすることで、他のプロダクトも現状を知る足がかりになります。 プロダクトにlintを入れなかった理由 Webアクセシビリティ関連のlintは、プロダクトのリポジトリに入れるのが素直なやり方かもしれませんが、今回はそうしませんでした。理由は2つあります。 ひとつは、エラーが出ても解消の仕方が分からず、負担になることです。lintを入れても、ルールの意味が伝わらなければ違反は残ります。 この懸念は、lintの置き場所を変えるだけでは解けません。外から回しても、理由が分からなければ同じことです。理由をどう伝えるかは、このあとに説明します。 もうひとつは、プロダクトのコードにライブラリを追加すること自体に判断が必要になる点です。どのルールを有効にするかの選定、ライブラリのアップデート対応、チームでの運用の取り決め。どれも必要な検討ですが、これを終えるまで着手できないとすると、また「機能開発が優先」となります。 そこで作ったのが、任意のディレクトリを指定して実行するとレポートが出力される、スタンドアロンのツールでした。ツールを落としてきて、パスを指定して回すだけです。プロダクトのコードには手を入れません。 lintはプロダクトに入れず、外から回す。この段階で優先したのは、着手のハードルを下げることでした。 ツールの構成とAIの担当範囲 処理は3つの段階に分かれています。AIが関わるのは②からです。 段階 やること AIの関与 ① 検出 Vue向けのアクセシビリティlint（eslint-plugin-vuejs-accessibility）で違反を洗い出す なし ② 説明 違反を一覧化し、なぜ引っかかったのかを書いたレポートに変換する あり ③ 改善 レポートを渡して、改善されたコードを出力させる あり（ここで詰まりました） lintの出力は「このルールに違反しています」までしか教えてくれません。なぜ違反なのかを知るには、ルールのドキュメントを都度見に行く必要があります。この確認の手間が、修正に取り掛かるまでの時間を延ばします。そこで、違反箇所とその理由を読めるレポートに変換する部分にAIを使いました。レポートにはサマリーと、ファイルごとの違反ルール・違反箇所が載っています。 ここまでは特に難しくありませんでした。ドキュメントを参照しながら書かせるだけだからです。 どのルールを対象にするかは、3つの条件で絞り込んでいます。 WCAG 2.2 適合レベルAの達成基準に対応する 静的解析で検出できる プロダクト固有の実装に依存しない 2つ目の条件が、このツールの守備範囲をそのまま決めています。フォーカスの移動順序が画面の見た目と合っているか、読み上げの順序として意味が通るか、操作に応じた状態の変化が支援技術に伝わるかは、Vueのテンプレートを構文解析するだけでは判定できません。実際のDOMとスタイルを解決したうえでの検査や、ブラウザでの操作確認が要る領域です。解析対象も <template> の中に限っていて、スクリプト側のロジックに起因する問題は見ていません。このツールで違反が検出されなくても、WCAG 2.2 の適合レベルAを満たしたことにはなりません。達成基準を満たせていないところの一部を静的解析で検出できる、という位置づけです。 ルールの絞り込み基準 採用・除外の判断は単純です。そのルールをWCAG 2.2 レベルAの達成基準と照らし合わせただけで、独自の重み付けはしていません。 基準に当てはめるだけでは決まらないルールが2つありました。 ひとつはラベルに関するルールです。ラベル要素で入力欄を囲む暗黙的な関連付けは、HTML仕様上は有効です。しかし、暗黙的な関連付けは、ブラウザと支援技術の組み合わせによっては対応されていない場合もあるので、明示的な関連付けをルールに入れています。 もうひとつは、フォーカスできる要素に role="presentation" が指定されていることを検出する no-role-presentation-on-focusable です。ARIAの仕様上、フォーカスできる要素では presentation の指定自体が無視されるため、指定しても効きません。こちらは、プラグインの推奨セットにも入っていないルールであることと、手動でのテストでカバーすることを理由に、初期の対象からは外しました。 3リポジトリに回して分かった傾向 現時点でツールを回したのは3つのリポジトリです。件数の集計はしていませんが、傾向は出ました。 違反が目立ったのは、プロダクト独自のUIコンポーネントでした。共通コンポーネント側で違反が少ないのは、そこがアクセシブルだからではなく、マークアップの実装がデザインシステム側にあって、このlintが見るプロダクトのテンプレートには現れないからです。デザインシステムを持っている組織なら、まずプロダクト独自のUIから見るのがよさそうです。 AIに改善を頼んで返ってきたコード レポートの出力までは問題なく動きました。 そのレポートをAIに渡して「アクセシビリティを改善して」と指示すると、lintのエラーが出なくなるコードが返ってきました。エラーは消えます。ただ、直してほしかった方向は違っていました。 具体例を2つ挙げます。いずれもVueのコードです。 例1： alt のない画像 < img : src = "logo" /> alt 属性がないため、スクリーンリーダーによってはファイル名などが読み上げられることがあります。AIが返してきたのは以下のコードです。 < img : src = "logo" alt = "" /> alt="" は「この画像は読み上げる必要がない」という意味を持つ書き方のひとつです。そのためlintは確かに通ります。 ただ、 alt に何を書くかは、その画像の用途と周りの文脈で決まります。ロゴのすぐ横に同じ内容のテキストが置かれているなら、二重に読み上げさせないために alt="" が適切な場合もあります。この例では、そうしたテキストがなく、画像だけが情報を担っているので、読み上げる必要があります。 < img : src = "logo" alt = "ラクス" /> 指摘を消すだけなら alt="" が最短です。ただそれを選ぶと、ロゴが伝えている情報は読み上げられなくなります。lintのエラーを消す方法は複数あり、どれを選ぶかで結果が変わります。 例2：クリックできる span 多かったのは、こちらのパターンです。元のコードはこうでした。 < span tabindex = "0" @click= "handleClick" > {{ text }} </ span > span はロールを持たない要素なので、支援技術に「操作できる要素」として伝わりません。キーボードイベントのリスナーもないため、EnterやSpaceで実行できない可能性があります。 AIが返してきたのは、次のコードです。 < span role = "button" tabindex = "0" @click= "handleClick" @keydown.enter.prevent= "handleClick" @keydown.space.prevent= "handleClick" > {{ text }} </ span > 指摘は消えます。ロールが付き、EnterとSpaceでも実行できるようになりました。支援技術からは操作できる状態ですが、以下のようなコードを期待していました。 < button type = "button" @click= "handleClick" > {{ text }} </ button > button を使えば、ロールもフォーカスもキーボード操作も標準で付いてきます。AIが出したコードは、 button が最初から持っているものを属性とイベントハンドラで組み立て直したものです。差が出るのは動く・動かないではなく、以後そのコードを触る人が同じ組み立てを維持できるかどうかです。 AIが提案したコードは、目視で確認して判定しています。多かったのは、セマンティックな要素を検討してほしい場面で、属性の追加で対応されてしまうパターンでした。 2つの例は性質が違います。例1では読み上げるべき情報が失われています。例2のほうは、主要な操作自体はできるようになっています。共通しているのは、lintのエラーを消す方法が複数あるなかで、元のコードを大きく変えない方法が選ばれたことです。指摘を消すことが目的になると、この選び方になるのだと思います。 AIが指摘を消す方向に向かう理由 原因は2つあると考えています。ひとつは検証のできない仮説ですが、もうひとつは今回の作りから直接たどれるものです。 仮説のほうは、AIが学習しているコードの側に原因があるのではないかと考えています。世の中にはアクセシブルではないコードが溢れていて、だからこそAIはそれらのコードをアウトプットとして出してくる。 span にロールを付けて操作できるようにしたコードは、実際のWebでも見かけます。ただ、モデルがそのコードを選んだ理由が学習データの偏りにあるのか、元のコードとの差分を小さくしようとした結果なのかは、外からは切り分けられません。 直接たどれるほうの原因は、こちらが渡している情報です。レポートに入っているのは、引っかかった箇所のコードと、その理由だけです。そのUIが何をするコンポーネントなのか、周りのコードとどう関係しているのかは入っていません。 alt の例がそのまま当てはまります。その画像がロゴなのか、本文の理解に必要な図なのか、単なる飾りなのかは、ファイル名とタグだけでは決まりません。文脈を見ないと決められない判断を、文脈なしで求めていました。代替テキストに何を書くかは、そのコンテンツを作った人が何を伝えたいかで決まります。そこはAIには判断できません。違反箇所のコードとlintの結果だけでは、その材料がありません。 これはWebアクセシビリティに限った話ではありません。静的解析の指摘をAIに直させるとき、渡しているのが「違反したルール」だけであれば、指摘を消すことが目的になります。検査が通ることと品質が上がることは別です。AIの出力がどちらに寄るかは、違反の条件だけを渡すのか、そのコードが何をするためのものかまで渡すのかで変わります。 次の課題はインプットの設計 ここから先は、まだ結果が出ていません。現時点の仮説は2つあります。 セマンティックな要素を使うことを優先させる WAI-ARIAの仕様を確認させる どちらも、属性で辻褄を合わせる方向に行かせないための指示です。ただ、指示文に書くだけで足りるのか、参照する資料まで渡す必要があるのかは、まだ検証していません。 ARIA Authoring Practices Guide（APG）のような、「このパターンはこうマークアップする」という指針が示されたガイドを参照させる案もありますが、これも着手前です。毎回ガイド全体を読ませるのは非効率なので、lintのルールに関連するAPGの箇所をリファレンスとして持たせる形も考えられそうです。 AIに任せられる範囲は、渡せる情報をどこまで設計できるかで決まります。今回の設計では、lintによる検出と、AIによる説明までは成立しました。改善まで任せようとすると、同じ情報だけでは足りませんでした。 今回の学びと、これから 今回の取り組みで得た学びのひとつは、AIによるWebアクセシビリティ向上の自動化は難しい、ということです。最終的に人間のレビューは必要で、だからこそ適切に判断できるように、Webアクセシビリティの知識をこれからもつけていきたいと考えています。 AIに任せる範囲を広げるほど、出てきたものを正しいと判断できる人が必要になります。Webアクセシビリティのように、ルールを通すことと、目的を果たすことがずれやすい領域では、その差が出やすくなります。 次は他プロダクトへの横展開ですが、その前にやることがあります。広げる前に、まず担当プロダクトのチームに展開して、誰でも対応できる運用にできるかを確かめます。ここが目の前のハードルです。 最後に、この記事の持ち帰りを4つに整理します。 Webアクセシビリティの向上に着手できていないなら、コードを直すところから始める必要はないかもしれません。まず「どこに問題がありそうかを知る」ところからなら、小さく始められます。 現状把握を始める段階なら、プロダクトにlintを組み込む判断を待たず、外から実行する方法も選べます。 デザインシステムを持っているなら、静的解析の指摘はプロダクト独自のUIに集まりやすくなります。探し始める場所の目安になるかもしれません。 検出はlintに、違反理由の説明はAIに任せられました。改善まで任せるなら、何を渡すかを設計する仕事が人間側に残ります。 直接コードの修正ができなくても、Webアクセシビリティを前に進めるアプローチはいろいろあると思います。思ったように取り組めずにいる方にとって、何かしらの参考になれば幸いです。

こんにちは。楽楽明細の開発をしている者です。 運用目線での顧客視点として、障害対応の話を書こうと思います。 障害が起きたとき、私が頭の中でどういう順番で何を判断しているのか。それを文章にしてみます。 はじめに 前提になる楽楽明細の事情 私の動き方 まず騒ぐ 何が起きているかをざっと把握する 顧客への影響を見極める 止血が要るかで動きを分ける 原因調査で意識していること そのケースがなぜ起きたかを追う 仮説を複数立ててから動く AI との分業 属人化させないために はじめに 開発の仕事は、機能を作りリリースしたら終わりではありません。ユーザーが日々何の問題もなく使用できるように安定した運用を保つところまでが開発の仕事です。 障害や不具合が起きると、程度の差はあれ、ユーザーが想定した通りに使えない時間が発生します。 システム開発においてもちろん理想は不具合を起こさないことが第一ですが、実際問題、あまり現実的ではありません。 Amazon の CTO である Werner Vogels 氏の言葉に "Everything fails all the time"（あらゆるものは、常に壊れる）というものがあります。AWS のような巨大なクラウド基盤でさえ、壊れないことを目指すのではなく、壊れても動き続けられることを前提に設計されています。 起こさない努力と同じくらい、起きたときにどう動くかが顧客への影響を左右します。この記事では、障害を起こさないための設計やテストの話はしません。起きてしまった後にどう動くと顧客の不利益を小さくできるか、という話だけを書きます。 前提になる楽楽明細の事情 動き方の前に、楽楽明細というプロダクトの性質を書いておきます。障害対応の優先度とデッドラインが、ここで決まるからです。 楽楽明細は、請求書や納品書などの帳票を発行して取引先に届けるクラウドサービスです。 Webでの公開やメール送付に加えて、郵送も扱っています。 ここで押さえておきたいのが、楽楽明細を契約しているのは帳票を発行する企業ですが、帳票を受け取るのはその先の取引先だという点です。 帳票が発行できない、届かない、という状態になると、契約企業だけでなく受取側にも影響が届きます。 受取側から見れば「請求書が来ない」「来たけど内容が違う」という出来事で、その問い合わせを受けるのは契約企業の担当者です。 一つの不具合が、契約企業の数だけでなく、その先の取引先の数に掛け算で広がっていってしまいます。 郵送の場合、時間の制約が加わります。郵送は外部の印刷・発送サービスと連携しており、その日のうちに発送するためのデータ送信には締め時刻があります。 郵送に絡む障害においては直せば済むでは終わらず、締め時刻までに直せなければ、その日の郵送が確実に遅れます。デッドラインが最初から決まっている障害対応です。 もう一つ、同じ障害でも機能によって温度感が違います。 管理画面の一覧の並び順が崩れる不具合と、帳票の生成が失敗する不具合では、対応の温度がまったく違います。 前者のような UI レベルの問題であれば、ユーザーには操作上の使いづらさなどは発生しているものの、運用が完全に停止してしまうところまではつながらないことが多く、次回リリースに載せて対応することでも大きな影響がない場合もあります。 後者の場合は、修正自体は容易だったとしても、その日のうちに直さないと運用自体が完全に停止してしまう大きなインシデントとなってしまいます。 対応の優先度は、コードの直しにくさではなく、誰にどこまで影響が届くかで決まります。 私の動き方 ここから本題です。異常に気づいてから原因調査に入るまで、私はだいたい次の順番で動いています。 まず騒ぐ 異常な状況を確認したら、原因が分かっていなくても、まず展開します。「○○の処理でエラーが出ています。原因はまだ不明です」くらいの一言で構いません。 最初にこれをやる理由は単純で、自分一人で抱えている時間が一番もったいないからです。 同じ事象を他の誰かが別の場所で見ているかもしれない。誰かが直前にリリースや設定変更をしているかもしれない。展開すればそういう情報が集まってきます。 空振りでも構いません。調べたら何でもなかった、で終わればそれでいい。「騒いだのに何もなかった」ことを気にして報告をためらう方が、後でずっと高くつきます。 何が起きているかをざっと把握する 次に事象を把握します。ここでは深追いしません。見るのは主に次の4点です。 どの機能で：エラー通知の発生元と、スタックトレースに出てくる処理の入り口 いつから：エラーログの初出時刻と、直前のリリースタイミングや本番環境での作業履歴 どのくらいの頻度で：同種エラーの件数の推移。単発か、増え続けているか どういうエラーか：例外の種類とメッセージ。データ起因か、接続などの環境起因かの当たりをつける ログとエラー通知を見て、5〜10分程度で全体像をつかむイメージです。 顧客への影響を見極める 事象がつかめたら、原因の前に影響を見ます。私が確認しているのは、次のような点です。 データは壊れないか。壊れているなら、今この瞬間も壊れ続けているか 影響は広がり続けるか。放っておくと対象のユーザーや件数が増えるか 特定の環境や条件でだけ起きているのか。全ユーザーか、特定の設定を使っている一部か この 3 点で、次に取る行動が決まります。 データが壊れ続けているなら、原因が分からなくても処理を止める判断が必要になります。 影響が広がらず、特定条件の一部ユーザーだけなら、止血よりも原因調査を急ぐ方が結果的に早く収束することもあります。 前の章で書いた温度感の話もここで効いてきます。郵送に絡む処理なら、影響範囲が小さくても締め時刻との距離を最初に見ます。 止血が要るかで動きを分ける 影響が見えたら動きを二つに分けます。 即時の止血が必要な場合 最初に考えるのは、そもそもフォールバックできないかです。 直前のリリースが怪しいなら切り戻す、新しい処理が原因なら元の処理に戻す。すでに動いていた状態に戻せるなら、それが一番速くて確実です。 フォールバックで逃げられない場合に、止血の方法を考えます。方法を決め、デッドラインを置き、妥当性を確かめる。この三つを済ませてから原因調査に入ります。 止血方法は、該当機能の一時停止、問題のあるデータの隔離、処理の手動実行への切り替えなど、状況によって変わります。 ここで大事にしているのは、止血そのものが新しい不具合を生まないか、あとで戻せるかを確認することです。急いで対応した結果、考慮不足や別の不具合につながってしまっては元も子もないからです。 デッドラインは、郵送なら締め時刻から逆算して置きます。「この時刻までに止血が終わらなければ、その日の郵送は諦めて関係部門に伝える」という線を先に引いておくと、判断がぶれません。 即時の止血が必要ない場合 暫定対処やユーザーへの案内まわりは他のメンバーに任せて、自分は原因調査に入ります。影響が限定的なら、中途半端な暫定対処を挟むより、原因を特定して正しく直す方が早いことが多いからです。 原因調査で意識していること そのケースがなぜ起きたかを追う スタックトレースを見れば、どの行で何のエラーが出たかは分かりますが、それは原因ではなく結果です。 たとえば NullPointerException が起きていた場合、null チェックを足せばエラーは消えます。 でも、なぜ null になるデータがそこに来たのかを追わないと、同じデータが別の処理で別のエラーを起こします。 データの発生源を追っていくと、行き着く先はだいたいこのあたりです。 直前の変更。リリース、設定変更、データメンテナンスなど 想定外の操作順や入力 別機能のバグで作られたデータ 特定の環境や設定でだけ成立する条件 エラーが出た理由より、そのケースが発生した理由を探さないと、同じことが当然再発します。 仮説を複数立ててから動く 事象を把握したら、調査に入る前に仮説を複数立てます。少なくとも二つ、できれば三つ。 前の節で挙げたようなパターンのうち、今回の事象はどれに当たりそうか、というところから組み立てていきます。 調査の軸がないと、ただソースやログとにらめっこしているだけの時間が発生してしまいます。 仮説を一つに絞って走り出した場合も同じで、その仮説がダメだったと確定した時点で手が止まり、次はどうしようかと考えなおす時間が発生します。状況によりますが、基本的に障害対応中は時間との戦いになるため、手を止めてしまう時間が発生するのは惜しいです。 複数仮説を立てておけば、一つダメでもすぐ次に移れる。仮説をつぶしていくことで、方向性を絞っていくこともできます。 仮説を立てたら、優先順位をつけて検証に入ります。検証で見るのは、主にエラーが発生したユーザーの操作の履歴と、実際のデータです。ログから操作の順番を組み立て、その時点のデータがどうなっていたかを見て、仮説と突き合わせる。合わなければ次の仮説へ、という繰り返しです。 AI との分業 最近の原因調査では、AIを活用している場面も増えてきています。 私がやっているのは、スタックトレースと自分が立てた仮説を Claude Code に渡して、ソースコードレベルの解析を任せるやり方です。渡すのはソースコードと例外情報の範囲までで、顧客データやログの実値は投入しません。 「この例外がこの行で出ている。仮説は A と B。それぞれの場合にコード上で何が起きるか確認してほしい」といった感じで指示を出し、呼び出し経路や条件分岐を追って、仮説ごとにコード上の裏付けを返してくれます。 その間に並行して、人間は本番のログや実データをもとに別観点で調査を進めることができます。 一方で、AI に投げる前の仮説の質は、結局こちらの責任です。仮説が的外れなら、AI は的外れな仮説をコード上で丁寧に裏付けてくれるだけです。前の節で書いた「複数の仮説を立てる」は、AI を使うようになってからむしろ重要になったと思っています。 属人化させないために 障害対応が特定の人に集まる理由は、調査スキルの差だと思われがちです。ただ、私が実際に効いていると感じているのは、対応の型が共有されているかどうかです。 障害は頻繁に起きるものではないので、経験の機会そのものが偏る。だからこそ、判断の順番を言語化して渡せるかが分かれ目になると考えています。 その順番がここまで書いてきたものです。私自身、毎回この通りに動けているわけではないですし、この通りやれば必ずうまくいくという話でもないのですが、迷ったときに立ち返る型としては役に立っていると思います。 ソースコードの解析は AI にかなり任せられるようになり、調査スキルの差を AI が埋めてくれる場面はこれからも増えていく一方で、この前段の判断は最後まで人の側に残ります。障害対応の重心はここにあると考えています。 繰り返しになってしまいますが、障害対応は起きた不具合を直すだけの仕事ではありません。楽楽明細では、影響は帳票を待つ取引先まで届きます。 その影響を見極めて、ユーザーの運用をいかに止めないか、早く再開できるようにするか。ここが一番大事なポイントです。

はじめまして。昨年新卒として株式会社ラクスに入社し、現在はHRソリューション開発部楽楽勤怠開発課でバックエンドエンジニアをしているmurosyoです。普段は楽楽勤怠の機能開発を担当しています。開発本部が掲げる 『顧客に価値を高速提供できるAIネイティブな開発組織への変革』 というビジョンのもと、ClaudeのSkillsやAgentsなどを整備・展開しています。 今回は、私がチームに導入を試みた 「Claude Codeを用いたIssueの自動解消」 の取り組みについて、構成の全貌や、実際にやってみて直面した「AIネイティブな開発ならではの壁」について、包み隠さずお話ししたいと思います。 はじめに 背景とゴール：「プログラムの不具合をいち早く修正し、お客様のユーザ体験を向上させたい」 Claude Codeを用いたIssue自動解消の全貌（実践編） フロー全体の解説と「Routines」の活用 今回の仕組みのメリット 導入で見えた「AIネイティブな開発」の壁 レビューの難しさ：コードの妥当性を測るための「深いドメイン理解」 AIとの協働をさらに進化させる：今後の展望 レビューコスト軽減への挑戦：意図を明確にするドキュメント化 Spec Driven Developmentへの拡大 おわりに はじめに 背景とゴール：「プログラムの不具合をいち早く修正し、お客様のユーザ体験を向上させたい」 自社で最も大切にしている価値観の一つが 「顧客志向」 です。お客様の業務課題を解決し、圧倒的に使いやすいサービスを提供し続けるためには、発生した不具合や細かな改善要望（Issue）に対して、いかに迅速にアプローチし、修正を届けるかが鍵となります。 しかし、日々の新規機能開発と並行してIssueを消化していくのは、どのチームにとってもリソース的に容易ではありません。「エンジニアの時間はより高度な設計やドメイン理解に使いたい。でも、目の前の不具合も一刻も早く直してユーザ体験を向上させたい」。 このジレンマを解消するためのゴールとして、 「Issueの調査からPR（Pull Request）作成までのフローをAIで半自動化し、開発効率を飛躍的に高めること」 を設定しました。 Claude Codeを用いたIssue自動解消の全貌（実践編） 試行錯誤の末、私は以下のようなフローでIssueの自動解消パイプラインを構築しました。 フロー全体の解説と「Routines」の活用 Claude Codeには、定型的なタスクを定義して実行できる「Routines」という機能があります。これを用いて、大きく2段階に分けたフローを構築しました。 ※下記に記載する内容はサンプルです。 Issueの起票 ユーザがリポジトリにIssueを起票します。 下記の内容を記載します。 発生している事象 再現手順 期待する挙動 修正対象のIssueにコード調査を依頼するラベルを付与します。 コード調査（1つ目のRoutine） コード調査の依頼が付与されているIssueを検索します。 見つかったIssueの内容を基に、Claude Codeがコードベースを検索・調査します。 ユーザへの確認事項の提示 コード調査の結果と、修正内容の実装にあたってClaudeが知りたい確認事項をIssue上にコメントとして記載します。 コード調査完了済みを示すラベルを付与します。 ユーザの回答 人間がそのコメントを確認し、確認事項に返信および修正方針が問題なければGOサインを、修正が必要ならフィードバックをIssueに返信します。 Issueに実装を依頼するラベルを付与します。 実装（2つ目のRoutine） コードの調査結果とユーザの回答結果を基に、Claude Codeが実際の実装（コードの変更）を行います。 AIレビューとテスト項目書の作成 実装後、Claude自身によるセルフレビューを実行し、さらに今回の修正に対するテスト項目書を自動作成します。 PRのDraft作成 以下の情報を記載したDraft PRを自動生成します。 実装内容のサマリー レビュー結果 テスト項目 対象のIssue番号 PRにはAIによって修正されたことがわかるラベルを付与します。 Issueには実装が完了し、PRの作成が行われたことを示すラベルを付与します。 ローカルでの動作検証と最終レビュー 最後に人間（ユーザ）が作成されたブランチをローカルに取り込み、動作検証を行ってPRをマージします。 今回の仕組みのメリット 今回の仕組みには多くのメリットがあります。 人間の稼働時間外にAIを働かせられる 例えば、夕方にIssueを起票し、夜間のうちに「コード調査」を実行しておきます。翌朝出社すると、Issueにはすでにコード調査の結果と実装方針、実装にあたっての確認事項が記載されており、人間はそれを読んで回答するだけです。これにより、日中の貴重な開発セッションのコンテキストスイッチを発生させることなく、並列で作業を進めることができるようになりました。 Issue上に全ての内容が記載されるため、Issueを確認するだけでどのような方針にしたかをいつでも振り返ることができる Issue上に当時の調査結果や修正案、修正方針がすべて残るため、後から見返したときに『どの調査結果を根拠にこの修正方針を選んだのか』を追うことができます。 ローカルPCを汚染しない 実装は全てクラウド環境（サンドボックス）で実施されているため、ローカルに余計なブランチが作成されることがなく、また、Claudeの修正がローカル環境に影響を与えるものであっても、修正内容を確認し、危険だと判断したら取り込まない選択ができるためローカルPCが汚染されません。 個人の環境に依存しないため、誰が操作しても再現性のある挙動を実現できる ローカルでIssueの調査と解消をしていたときは、実行環境が各自のPCに依存するため、ツールの起動条件や調査結果の出力内容が環境ごとに変わることがありましたが、クラウド環境（サンドボックス）で動作させることで、誰がやっても同じ環境・同じ設定で実行されるため、挙動が安定しました。 Human in the Loopを挟むことで段階的に進めることができる 最初のRoutineでコードの調査結果を基に実装方針を検討し、開発者に確認するというフローを挟むことでClaudeが勝手に設計・実装を行って、意図した内容と大きく異なる実装になってしまうということがないようになりました。 誤った実装で余計なトークンを使用しなくなったことにより、コスト的にも安価に済ませることができます。 導入で見えた「AIネイティブな開発」の壁 ここまで聞くと夢のような仕組みに思えるかもしれませんが、実際に運用してみると、想像以上に大変な課題に直面しました。 レビューの難しさ：コードの妥当性を測るための「深いドメイン理解」 最も大きな壁は、 「人間によるコードレビューの負荷」 でした。 Claude Codeが生成するコードは、文法的には正しく、テストも通るものが大半です。しかし、楽楽勤怠が持つ複雑なビジネスロジックや、特有のドメイン知識に本当に即しているかどうかは、パッと見ただけでは判断できません。 AIが「なぜこの実装アプローチをとったのか」という意図を正確に理解するためには、レビュワーである人間側が、結局のところ既存のコードベースを深く読み込み、AIの思考プロセスをリバースエンジニアリングして紐解く過程が必要になります。 この「AIの実装が本当に正しいか、コードを読んで理解する」という作業が思いのほか重く、AIによってコーディングの時間は削減されたものの、レビューの時間が長引いてしまい、結果として恩恵が一部相殺されてしまうというジレンマを感じました。 AIとの協働をさらに進化させる：今後の展望 これらの課題を踏まえ、私たちはこの仕組みをさらにブラッシュアップしていく予定です。 レビューコスト軽減への挑戦：意図を明確にするドキュメント化 レビューコストが高い問題については、「既存コードの書き方に合わせること」と「参照先や実装意図を明示すること」を、プロンプトやRoutineのルールとしてAIに徹底させるアプローチを試しています。 「〇〇のディレクトリにあるXXパターンの実装を踏襲しました」「理由は△△だからです」というサマリーがPRに明確に記載されていれば、レビュワーの認知的負荷は劇的に下がると考えています。 Spec Driven Developmentへの拡大 もう一つの展望は、この仕組みを 「Spec Driven Development（仕様駆動開発）」 に応用することです。 「仕様書（Spec）」をIssue上で管理し、合意が取れたSpecを基にAIが実装を行う。このサイクルを回すことで、ドメイン知識のズレを実装前に吸収し、より本質的な「顧客価値の最大化」にフォーカスした開発ができるのではないかと期待しています。 おわりに AIにコードを書かせることは簡単になりつつありますが、それを実運用に載せ、真に「ユーザ体験の向上」に繋げるためには、人間とAIの協働プロセスを泥臭くデザインしていく必要があります。 課題はまだまだ山積みですが、ラクスのカルチャーである「小さく試して大きく育てる」の精神で、これからもAIネイティブな開発組織への変革に挑戦していきたいと思います。 この記事が、同じようにAIツールのチーム導入を模索している皆さんの参考になれば幸いです！

前提：楽楽明細とは別のアプリとして作った 起きたこと：12機能を1本のプルリクにまとめた 原因：4層の名前までしか決めていなかった 対策：機械に判定させる範囲を広げ、人が見る範囲を絞る 実例：レビューで通せなかった箇所 次にやるなら：プルリクの切り方から変える チェックリスト：着手前に決めておく項目 編集後記：インタビューを終えて ラクス技術広報です。 開発本部では、各部署のAI活用の取り組みを技術広報がインタビューし、記事にしています。今回は電子請求書発行システム「楽楽明細」の新しいオプション機能を、AIにほぼ実装させて約2か月でリリースした事例です。 本記事は、AIを使って順調に機能開発が進んだ話だけでなく、うまくいかなかったこと・その対策をまとめています。 AIに任せる範囲を広げる前に、正しさを機械が判定できる状態を作る。 今回はこの状態を作らないまま進めました。その結果、機能ごとに実装の仕方がばらばらになり、1機能のレビューで入った指摘を他の機能に横展開できず、同じ指摘を機能の数だけ受けることになりました。 納期の都合で12機能を1本のプルリクエストにまとめたことも重なり、変更ファイルは700を超え、サーバーサイドのレビュー担当が全量を確認し終えるまでに5営業日かかっています。 新規プロダクトでAI駆動開発を始める方 AIが書いたコードのレビューが追いつかないと感じている方 に向けて、着手前に決めておく項目を記事の最後にチェックリストとして置きました。是非ご参考ください。 ［図1：任せる範囲と、機械が判定できる範囲］ 前提：楽楽明細とは別のアプリとして作った 　 楽楽明細は、請求書や支払明細などの帳票を電子発行するクラウドサービスです。帳票のもとになる売上データは、お客様が販売管理システムやExcelで管理しているものを取り込みます。 販売管理システムを使っていないお客様は、売上データをExcelで管理しています。 ・営業や拠点ごとにファイルが分かれ、どれが最新かわからなくなる ・転記のときにミスも起きる ここを解決するために作ったのが、今回の 売上登録オプション です。専用画面で売上データを入力すると、そのまま請求データとしてCSV出力できます。 仕様はプロダクトマネージャーが決めました。AI（Claude）でプロトタイプを作り、動くものをお客様に見せながら40社に話を聞いています。話を聞くうちに最小限の機能で導入いただけるとわかり、最初のプロトタイプから機能を約30%削って、CSV出力と税額計算に必要な設定に絞りました。 楽楽明細本体には手を入れず、別のアプリとして切り出しています。長く運用してきた本体にAIを入れると既存機能を壊す可能性があるため、影響範囲を限定してAIに任せる範囲を広げる判断です。 項目 内容 期間 開発決定4月7日 → リリース5月末（実質2か月未満） 体制 設計・実装は2026年1月入社の川島卓大さんがほぼ一人。 サーバーサイドとフロントエンドで各1名がレビュー。 技術 Java、Spring Boot、React、TypeScript、PostgreSQL AIの使い方 仕様の書き起こしはClaude Code、kiro（cc-sdd）でspec化してエージェントに読ませる。 実装の主軸はCodex。 git worktreeで機能ごとに作業を隔離し、複数セッションを同時に走らせる。 起きたこと：12機能を1本のプルリクにまとめた 　 実装に使える期間は実質1か月弱で、機能は12ありました。機能ごとにプルリクエスト（以下プルリク）を切ってレビューを待つ余裕がないため、まず全機能をつなげて動かし、そこから改善する方針を選びました。 項目 実績 変更ファイル数 700超 サーバーサイドのレビュー 機能単位で半日〜1日。 最初のプルリクを全量見切るまでに5営業日（期間で2週間弱）。 フロントエンドのレビュー 大型プルリクと、機能単位に分割された後続15件のフロント部分を合わせて2人日。 GitHub Copilotによるレビューも入れていましたが、人手で見きれる量を超えています。機能ごとに切り分けてレビューできたのは、パッケージ構成をfeature-firstで先に決めていたためです。 原因：4層の名前までしか決めていなかった 　 プロダクトマネージャーからの要求仕様書は、お客様の求めるものが整理された状態で渡されています。ただ、そのままAIに渡せる粒度ではなかったと川島さんは語ります。 「そのままでは渡せませんでした。特に受け入れ条件と例外系が足りませんでした。」 そこで要件を「WHEN 条件 THEN 結果」のEARS形式で1アクション単位に分解し、「IF 制約 THEN 拒否」の例外パスを正常系と並べて書いてからspecに落としました。 実装側で先に決めていたのは、feature-firstのパッケージ構成と、DDD（オニオンアーキテクチャ）の4層の名前までです。層の中で誰が何を担うのか、検証はどこでやるのか、副作用はどこに置くのかは決めていませんでした。 その状態で機能ごとに並列でエージェントを走らせると、1機能のレビューで入った指摘を他の機能に横展開できず、同じ指摘を機能の数だけ受けることになりました。 「仕様自体は要件通り作成できているものが多かったが、責務が分離できていないものが多く、レイヤー間の妥当性を見る時間が多かった。」 要求がテストできる形になっていても、実装方針が決まっていなければ、AIはそれぞれの解釈で書きます。 対策：機械に判定させる範囲を広げ、人が見る範囲を絞る 　 ［図2：判定を3段に分ける］ CIとpre-commitは最初から入れていました。ルールの書き出しとマージゲートの追加は、機能ごとに実装がばらばらになった反省から足したものです。 「一番効いているのは『できました』と言わせず証拠を出させることです。」 川島さんは、サブエージェントの「テストが通った」という報告も鵜呑みにせず、親のエージェントがdiffとテスト出力を自分で確認します。 レビューは一次をGitHub CopilotとClaude Codeのスキルで出し、人が二次で見ます。観点が複数あるときは同じエージェントに全部任せず、観点ごとにサブエージェントを分けて並列で走らせます。指摘にはmust、should、ask、imo、nitのラベルを付け、対応するかどうかを人が判断しやすくしています。 実例：レビューで通せなかった箇所 　 本機能にて、サーバーサイドとフロントエンドのレビューを担当した2人に「レビューで通せなかった箇所」についてお伺いしました。 領域 レビューで通せなかった箇所 サーバーサイド メール送信のように非同期で構わない処理が、トランザクションの中に入っていた。 初期のプルリクでは、メールは送信されたのにDBがロールバックされ、無効なパスワード初期化用URLがユーザーに届く実装になっていた（リリース前に修正）。 サーバーサイド 業務ロジックがユースケースやインフラの層に流れ出す責務違反。 サーバーサイド N+1が起きやすい構造。 明細行20行の売上データを取得するのに、最初はSQLが23本走っていた。 フロントエンド 方針はバックエンドで検証して送信時に表示することだったが、全画面にリアルタイムバリデーションが入っていた（全画面から削除）。 フロントエンド すでにある共通コンポーネントを使わず画面ごとに直書きし、ドラッグ・アンド・ドロップも複雑に自前実装していた（ライブラリを使う形に置き換え）。 フロントエンド テーブル内のテキストフィールドに1文字打つごとに、テーブル全体が再レンダリングされていた。 レビューを担当した2人が、共通して口にしたことがあります。 「『動く』のと『そのまま出せる』の間には距離がある」 また、これから同じ進め方を始めるチームへ、2人からのコメントです。 サーバーサイド　レビュー担当者 「設計、実装の前にどうやってAIをハンドリングをしていくかという工程をちゃんと設けるべきではあった。期日までが短く急ぎ早で始めたものの手戻りも多く、事前準備をちゃんと設けていても間に合わせられていたのではと思う。 」 フロントエンド　レビュー担当者 「レビューする側もAIを使っていいということ。作る速度が上がる分、見る側もAIで理解スピードを早めないとレビューが追いつかなくボトルネックになる。」 次にやるなら：プルリクの切り方から変える 　 ［図3：プルリクの切り方］ 切れ目を先に決めておけば、レビューは内側から外側へ積み上げる順に流れます。 一人でフルスタックに進めた体制では、フロントとバックエンドの間で調整が発生しないため、動くものを作る速度は出ました。一方で、一人にかかる負担は大きくなりました。API規約を先に確定させれば、フロントとバックエンドを分担できます。着手前にAIのハンドリングを詰める工程を置くことも、次の案件に向けた課題として残りました。 チェックリスト：着手前に決めておく項目 　 冒頭でもお伝えした通り、本取り組みから得た知見を基に着手前に決めておく項目をまとめました。 ご自身のプロジェクトに当ててみてください。 仕様と設計で決めておくこと （→ 原因の章 ） □ 受け入れ条件と例外系を、1アクション単位で書き出したか（EARS形式など） □ 各層で誰が何を担うか、検証はどこでやるか、副作用はどこに置くかを決めたか 機械に判定させる仕組み （→ 対策の章 ） □ CIで必須にする項目を並べたか（lint、format、型チェック、単体テスト、secret scanning、依存パッケージの実在チェック） □ テストを実データに近い環境で流せるか（Testcontainersなど） □ 機械では拾えない観点を、プロジェクト固有のレビュー観点として文字にしたか □ エージェントに、テスト出力とdiffを証拠として出させる運用にしたか 分割の単位 （→ 次にやるならの章 ） □ API規約（インターフェース）を、実装より先に確定させたか □ プルリクの切れ目を、レビューできる大きさで先に決めたか 最後に、川島さんからのメッセージです。 「AIに任せる範囲を広げる前に、正しさを機械が判定できる環境を先に作ることが大事だと思いました。最初の壁はコードが書けないことではなく、動いているように見えて設計方針から外れたコードが、レビューの追いつかない速度で積み上がることです。AI駆動開発で変わるのは、コードを書く仕事の比重です。良し悪しを定義し検証する仕事へ重心が移ります。ツールは半年で入れ替わりますが、この土台はどのツールに乗り換えても効き続けます。」 編集後記：インタビューを終えて 　 取材していて印象に残ったのは、川島さんもレビュー担当の2人も、うまくいった話より「次はこうする」を具体的に話してくれたことでした。700ファイルのプルリクは、社外に出すには気の重い話だと思います。それでも数字と経緯をそのまま出してくれたので、この記事が書けました。 開発本部では、うまくいったところとやり直したいところの両方を、これからも技術広報が聞いてご紹介していきます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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