朝、森を歩いていた旅人が、木を切っている木こりを見かけました。夕方、同じ道を戻ると、木こりはまだ同じ木を切っています。見ると、ノコギリの刃はぼろぼろに欠けていました。 旅人が声をかけます。「木こりさん、ノコギリの刃を研いだらどうですか」。木こりは答えます。「木を切るのに忙しくて、研いでいる暇なんてないんだよ」。 『7つの習慣』の「刃を研ぐ」の文脈でよく引かれる寓話です。初めて聞いたとき、私は笑えませんでした。私のことだったからです。 こんにちは。KNDです。 仕事を進めるだけでは、仕事しか進みません。自分の仕事の仕方やスタンスをチェックして、調整して、次の行動を決める。この「自分自身への PDCA」が成長には要る、と私は思っています。 ただ、分かっていても回らない。それが木こりのジレンマです。私の個人の振り返りも続きませんでした。正確に言うと、書く週は書くのですが、 Keep / Problem / Try（KPT）を埋めて満足して終わる。翌週には先週何を書いたか覚えていない Try が「もっと主体性を発揮する」のような抽象的な宣言になり、当然のように果たされない 忙しい週は後回しにする。個人の振り返りには締切も相手もいないので、サボっても誰も困らない という状態でした。刃を研いだ方が速いと分かっていて、研げない。 この記事は、その「研げない」を、気合ではなく仕組みで解きにいった5ヶ月の記録です。やったことを一言で言うと、 毎週金曜12時に、Claude Code が向こうから振り返りにやってくる ようにしました。 木こりのジレンマ ■目次 1. 「研ぐ時間がない」の正体は、やる気ではなくコスト 2. 仕組みの全体像 3. 準備ゼロ。金曜12時、向こうから振り返りがやってくる 4. 雑でいい。整えるのは AI の仕事 5. 忘れない。1ファイル追記で AI に長期記憶を持たせる 5-1. やり逃げ防止 5-2. 週をまたいだパターン検出 6. 続けていたら、自分の成果を自分が見落としていた 6-1. デフォルトの AI は、優しすぎる 6-2. 「当たり前フィルタ」の発見 6-3. AI も間違える。事実を保証するのは自分 7. Try を「宣言」から「実験」に変える 8. 足りなかったのは相手ではなく、期日だった 9. 5ヶ月で何が変わったか、続けるための小さなルール 9-1. 変わったこと 9-2. 続けるために足したルール 10. 注意点 おわりに 1. 「研ぐ時間がない」の正体は、やる気ではなくコスト 最初は、続かないのは意志が弱いからだと思っていました。ただ、続かなかった理由を「かかっていたコスト」として並べてみると、別の構造が見えてきました。私の場合、払っていたコストは3つです。 振り返りが死ぬ理由 払っていたコスト 「さあやるぞ」と自分で始めないといけない 準備コスト。忙しい週ほど、始める気力が先に尽きる 人に見せる前提で、ちゃんとした文章にしようとする 品質コスト。書くのが億劫になり、書いても本音が丸まる 先週、先月に何を書いたか自分で覚えていないといけない 記憶コスト。毎週ゼロから書くので、点が線にならない そして4つ目。この3つを払わなくても、誰も困らない。相手がいないので、締切が永遠に来ない。 逆に言えば、この4つを仕組みで消せば、意志に頼らなくても回るはずです。そう考えて、AI に「向こうから来てもらう」設計にしました。 2. 仕組みの全体像 言い換えると、仕事の仕方の PDCA が「始まらない」「C で止まる」「D まで行かない」理由を、一つずつ潰しにいきました（この記事では C＝チェック、A＝調整、P＝次の Try を決める、D＝実行、の順で使っています）。打ち手は5つです。4つは第1節のコストを消すもので、残りの1つは運用してから分かった問題（AI が優しすぎる）への手当てです。 消したいコスト 打ち手 PDCA のどこを担うか 準備コスト プッシュ型起動。Windows のタスクスケジューラで、毎週金曜12時に Claude Code が起動する C が始まる 品質コスト 雑に書いていい。評価の物差しと出力フォーマットを AI 側に持たせ、整えるのは AI の仕事にする C が続く 記憶コスト 記録を1ファイルに追記し続け、AI の長期記憶にする C が診断になり、A と P（Try の書き直し）に繋がる 「優しすぎて何も変わらない」 AI の「いい人モード」を外す指示 C を甘くしない 「相手がいない」 Try に期日を付けて、人に言う。AI はその練習相手 D まで行く 仕組みの全体像 3. 準備ゼロ。金曜12時、向こうから振り返りがやってくる 仕組み自体はそっけないです。Windows のタスクスケジューラで、毎週金曜12時に Claude Code を起動するだけ。 プログラム: cmd.exe 引数: /k cd /d C:\work && claude %date%の週次コンピテンシー評価を振り返ります。Keep/Problem/Tryで一言ずつ書きます。 タスクスケジューラ（Windows） 短い1行ですが、設計意図が4つ詰まっています。 /k : コマンド実行後もウィンドウを閉じない。そのまま Claude Code との対話が始まる %date% : 当日の日付がプロンプトに入り、「どの週の記録か」が自動で決まる プロンプトが一人称の宣言文 : 「振り返ります」「書きます」。金曜の自分に「やるぞ」と期待しても裏切られるので、ウィンドウが開いた瞬間、もう書き始めるしかない状態を作る コマンド名を覚えなくていい : プロンプトに「コンピテンシー評価」とあるだけで、コンピテンシー評価に関するスキルが自動で起動する（このスキルは第4節で説明）。覚えることが無いのが、そのまま「運用が続く」に直結する 金曜12時にしたのは、AI の回答待ちのような5〜10分の隙間で書けるからです。 4. 雑でいい。整えるのは AI の仕事 ウィンドウが開いたら、私は雑に書きます。本当に雑です。 keep 設計書の1稿出した。AIに書かせて全部読んで直した。初動が楽 problem レビュー対応、期限聞かれてから出した。だめ 稼働入力 2週分たまってる。。 これはあくまで一例で、言いたいことが溜まっている週は長文を殴り書きすることもあります。粒度も量も、その週次第。Try が無くても気にしない。人に見せる文章ではないので、文の体裁も、順番も、整えません。 この「雑でいい」が、仕組みの中でかなり重要でした。書き始めるハードルが下がるだけでなく、本音が丸まらなくなります。 人に話す前提の振り返りには「これを言ったらどう見えるか」というフィルタが入る。AI 相手だとこれがゼロになり、「納得していなかったのに、角が立つと思って折れた」のような体裁の悪い事実を、そのまま出せる。振り返りの精度は入力の正直さで決まるので、これは思った以上に効きました。 雑な入力を「診断」に変えるために、AI 側には2つのものを持たせています。 1つ目は、評価の物差しです。 弊社には等級ごとに「この等級ならこういう行動が期待される」という定義があり、その Markdown（md）版を AI に読ませています。 第3節で自動起動していたスキルの正体は、別のチームのエンジニアが作ってくれたコンピテンシー評価用のスキルです。等級定義の md と記載ガイドラインが同梱されていて、これがそのまま物差しになります。 2つ目は、出力フォーマットの固定です。 毎回、KPT、各行動が「今の等級の要件か、一つ上の要件か」を示す表、辛口の解剖メモ、判定可能な形に直した Try、来週の確認観点、の5つの要素で返ってきます。 物差しとフォーマットがあると、雑に書いた Keep に「それは今の等級で求められる行動か、一つ上の行動か」という軸が入ります。「いい一週間でしたね」という感想ではなく、基準に照らした診断が返ってくる。 5. 忘れない。1ファイル追記で AI に長期記憶を持たせる この仕組みの本体は、たぶんここです。 振り返りの結果は、毎回同じ md ファイルに追記します。AI は毎週、そのファイルを頭から読んでから会話を始める。つまり AI はこれまでの記録を持った状態で、今週の話を聞いている 。 効果は2段階ありました。 5-1. やり逃げ防止 会話は毎回「先週の Try はどうでしたか」から始まります。しかも申告が鵜呑みにされない。 3回目の振り返りで、こんなやり取りがありました。 AI : 先週の Try は「レビューの場で、質問や提案を1つ出す」でした。どうでしたか。 私 : 今週は、該当する機会がありませんでした。 AI : 今週の Keep に「仕様書レビューで『このケースは除外する』と言われて、『結合テストは網羅でやるべきでは』と返した」とありますね。これは、まさにレビューの場で提案を出したことになりませんか。 私 : ……言われてみれば、そうですね。 やった本人が、Try の達成だと認識していなかった。この週から「Keep を書いたら先週の Try と照合する」手順が加わりました。 5-2. 週をまたいだパターン検出 これは運用して初めて分かった効果で、単発の AI 壁打ちでは原理的に起きません。 テスト作業を効率化する小さなツールを自作して、チームに共有したことがありました。次の Try は「実際に1人に使ってもらって、フィードバックをもらう」。 ところが、この依頼が5週間出せませんでした。「ツールを磨く」「共有範囲を広げる」は毎週できているのに、依頼だけが毎週「未達」として積まれていく。 4週目に AI が出してきた診断は、同じ週の2つの行動の対比でした。 私のチーム宛てに来ていた、誰の担当でもない設定の修正依頼は、自分から拾ってその日に直せた。詳しくない技術でも、AI に聞けば壁は溶ける 自作ツールの使用依頼は、4週間止まっている 技術の壁は越えられるのに、人に負荷をかける依頼だけを避けている。5週目には「スケジュールの問題ではなく、回避だ」と言い切られました。 実際、軽い依頼ではありませんでした。相手が慣れているテストの進め方を、私のツールに切り替えてもらう。便利になるか、かえって手間が増えるか分からない変更です。しかも自分で始めたことなので、期限もない。先送りするには十分でした。 6週目に依頼を出すと、翌日には使ってもらえ、フィードバックももらえました。 その週、AI はもう1つの行動を並べて、診断を絞り込みます。同じ週、私は新人の日報にコメントを書いていました。誰に言われるでもなく、すぐに書けている。相手に負荷のない「贈り物」はすぐ出せて、相手に手間を負わせる「依頼」だけが5週間止まった。避けているのは対人のやり取り全般ではなく、特定の1人に負荷をかける依頼だけだ、と。 毎週ゼロから書く振り返りでは、何週も離れたこれらの行動が同じ視界に入ることがありません。記録が1ファイルに乗っているから、AI が点を線として読める。 6. 続けていたら、自分の成果を自分が見落としていた 6-1. デフォルトの AI は、優しすぎる そのまま使うと、AI は何を書いても「素晴らしい取り組みですね」から入ります。気持ちよくはなるけれど、何も変わらない。 なので、AI の「いい人モード」を外す指示を入れています。一時期話題になった「AI の良い人フィルターを外す」プロンプトと同じ発想で、肯定から入らない・避けている盲点を指摘する・自分に嘘をついていたら教える、といった趣旨の指示です。実際に、容赦のない指摘が返ってきます（プロンプトに口調の指定は無いのに、なぜか口調まで強めになります……）。 この指示の効き目を思い知った回があります。10月のある金曜、なぜか辛口の指示が読み込まれないまま分析が始まりました。返ってきたのは、長いだけで何の役にも立たない文章でした。「物足りない」と言って起動し直し、やっといつもの診断が返ってきた。辛口は、あったら嬉しいオプションではありません。この仕組みの前提です。 6-2. 「当たり前フィルタ」の発見 辛口にしたら叱られるだけかと思っていたら、一番多く言われたのは逆のことでした。「あなたはこれを Keep に書いていない」です。 一番効いたのは8月の回です。ある文書の期限を優先して振り返りを1回飛ばし、次の回で2週分をまとめてやりました。私が書いた Keep は3つ。AI は PR の一覧を開いて、こう返してきました（実際のやり取りを一般化しています）。 AI : 設計文書の初版が、8月の第1週にマージされています。自分で決めた期限の当日です。Keep の候補にも入っていないのはなぜですか。 私 : 追加の修正がまだ揉めていて、説明の場も延期になったので……。それに、列挙していたとしても Keep には書かなかったと思います。過大評価ではないですか。 AI : 揉めているのは追加の修正の方で、初版ではありません。初版はレビューを通ってマージ済みです。過大評価かどうかは、感覚ではなく現物で判定できます。 その期でいちばん重要な出来事でした。「延期」という直近の悪い知らせが、もう終わっている成果を丸ごと塗りつぶしていた。忘れていたのではなく、知っていて、書くほどのことだと思えなかったのです。 AI はさらに、6月の回に自分で書いた指摘を引いてきました。振り返りで最初に出てこない行動は、月次の 1on1 や期末の評価では確実に消える。これがその最大の実例だ、と。2ヶ月前の自分の言葉を持ち出してくるのは、記録を全部読んでいる相手ならではです。 5ヶ月続けると、この「当たり前フィルタ」には変種があることも分かってきました。 一つ上の等級に相当する行動を、下の等級の言葉に翻訳して書く。実装を「早く、指摘なく終わらせた」と書いた週、PR で設計に提案して採用された事実は、聞かれるまで出てきませんでした 行動したのに「今週は機会がなかった」と申告する（自分の行動が Try に該当すると気づいていない） やっていることを、やっていないと思い込む。「期日はあまり言ってこなかった気がする」と書いた週、記録を数えたら3週で8回言っていました 仕組みや段取りの工夫は Keep に上がるのに、対人の「攻め」は上がらない。上司の提案に別の案を論理で返して合意を得た週、それは私の Keep に無く、AI が PR のレビュー履歴から拾い上げてきました 共通するのは、嘘も謙遜も無いことです。本気で「書くほどのことではない」と思っている。だから自力では直せない。 これは私だけの癖ではないのかもしれない、とも感じています。謙遜する人の多い日本の職場なら、同じフィルタを持っている人は少なくないのではないでしょうか。 6-3. AI も間違える。事実を保証するのは自分 ただし、AI の拾い上げが全部正しいわけではありません。この振り返りは Claude Code 上で動いているので、AI は PR や Slack の送信履歴を開いて突き合わせに行きます（Slack は MCP でつないでいます）。それでも間違えます。 たとえば、私がレビュー依頼の順番をわざと遅らせていたのを、AI が「無駄な待ち」と批判してきたことがあります。実際には、以前 1on1 でもらった助言に沿った順番でした。そう伝えて結果を見せると、AI は撤回しました。 逆に、AI 自身が書いた未レビューのドラフトを私の成果だと思い込み、「今期最強の成果物」と数えてきたこともあります。これは突き返しました。第6-2節とは、ちょうど逆向きです。 過大は削り、過小は主張する。AI は物差しにも記憶にもなるけれど、事実の最終保証者にはなれません。記録の信頼性を最後に支えるのは、本人が事実を盛りも削りもしないことです。 7. Try を「宣言」から「実験」に変える 振り返りが次に繋がらない理由のひとつは、Try の書き方にあると思うようになりました。 5月のある週、レビュー対応の予定を自分から出さず、上司に「いつ対応？」と聞かれたことがありました。その反省で書いた Try が「全タスクで主体性を発揮する」。悪くない宣言ですが、達成したかどうかを金曜に判定できません。判定できないものは、未達にもならない。だから何も変わらない。 AI に書き直させると、こうなります。 次にレビュー指摘を受けたら、聞かれる前に24時間以内に「対応範囲・完了予定日・次のレビュー出し先」を自分から上司に提示する。 誰に、何を、いつまでに。できたか判定できる形です。そして未達なら、未達と記録される。 未達になる Try は毎週あります。ただ、「5週間出せなかった依頼」がそのまま壁の発見に繋がったように、 未達の記録は失敗ログではなく診断データになります 。 これは、仕事の中身とも繋がっています。等級定義に書かれた行動は、私の読み方では「顧客に届く価値を、どれだけ自力で、周りを巻き込んで、速く出せるか」の段階です。レビュー対応の期日を自分から言う、という小さな Try は、リリースの予定を守ること、つまり顧客との約束を守ることに直結しています。研ぐのは、木を切るためです。 8. 足りなかったのは相手ではなく、期日だった 9月の記録に、私はこう書いていました。 人にやることを出していくといい。人との約束は破れないから。 AI の返事は「半分正しい」でした。記録の中に反例があったからです。 8月の終わり、レビューの指摘を直して「ご確認お願いします」と返した件があります。相手は翌日にコメントをくれたのに、私はそのあと8営業日、返していません。一方で、「明日出します」と相手に言った文書は、翌日に出せています。 違いは期日でした。「ご確認お願いします」には、自分の期日がありません。効いていたのは、人に言ったことではなく、 いつまでにを自分の口で言ったこと でした。 そこで、期日を2か所で口に出すことにしました。 1つは Claude です。 返信や資料の下書きができたら、毎日使っている Claude に「いつ出すか／何の後に出すか」を言う。言えないなら、後回しにしているだけ。AI 相手でも、日時を言っておかないとなあなあになるのは同じです。そして人に言うよりずっとラフに言えるので、期日を口にする練習になります。 もう1つは上司です。 10月のある金曜、振り返りの日の午後にちょうど 1on1 があり、その日に決めた Try を口に出しました。「レビューの指摘をもらったら、いつまでに直して返すかを先に伝える」。上司は、じっくり耳を傾けてくれました。私がしたのは、口に出して聞いてもらうことだけです。それでも、人に言った後は「やっていかなければ」という気持ちが一段上がります。この回から、Try は1つに絞って 1on1 で口に出しています。 結果は、まだ途中です。9月半ばからの3週で、外に向けて言った期日は8回。守れたのは3回でした。言えば守れる、というわけではありません。それでも、言ってあれば、崩れそうになった時点で自分から調整を切り出せます。 役割分担はこうです。 掘るのは AI と。 忖度がなく、体裁の悪い事実をそのまま出せる相手だから、正直に掘れる。 期日は人に言う。 AI は、そのための練習相手です。 9. 5ヶ月で何が変わったか、続けるための小さなルール 9-1. 変わったこと 続いた。 5ヶ月で19回。皆勤ではなく、体調や繁忙や連休で飛ばした週もあります。ただ「途切れてそのまま消滅」は起きていません。やる気を必要としない設計にしたからだと思っています。 行動が変わった。 4月の記録には、チームの運用で気になる点があったのに「まあいいか」で動かなかった、とあります。6月には、結合テストで検証環境の取り合いが起きているのを見て、QA に「調整用の場所を作りませんか」と自分から持ちかけました。話はスプレッドシートでの管理に落ち着き、環境の調整がしやすくなりました。振り返りが先か行動が先かは、正直に分離できません。ただ、記録の上では別人です。 振り返りが平日に食い込み始めた。 仕事中に何かつまずくと「これは金曜の振り返りで書こう」と、その場で考えるようになりました。反省を捕まえる網が、金曜だけでなく普段から張られている状態です。狙い以上の効果でした。 9-2. 続けるために足したルール 振り返りの仕組みは、立ち上げより延命の方が難しいです。5ヶ月の間に、破綻しかけては直したルールを挙げます。 翌営業日ルール : 金曜に急ぎの仕事があれば、無理せず翌営業日にやる。「来週まとめて」が消滅の入り口なので、先送り先を1日に固定する。ただし、1日の遅れでも影響は出ます。月曜に回した週の記録には「月曜に回すと処方が1週間分抜ける」とありました。翌営業日はあくまで逃げ道で、基本は金曜です 5分の縮退運転 : それも無理な週は「今週作ったもの・出したものの列挙だけ」を5分でやる。内省は後日でいい。振り返りの第一の価値は内省ではなく 捕捉 で、捕捉だけは後から取り戻せません。第6-2節の設計文書も、振り返りを1回飛ばした間の出来事でした 列挙は記憶ベースでなく成果物ベース : KPT を書く前に、PR 一覧や案件フォルダの更新ファイルから「作ったもの・出したもの」を機械的に並べる。記憶ベースだと、当たり前フィルタを通過したものしか出てこない 人に出したものは Slack の送信履歴から引く : 人に向けた行動ほど記録から落ちる、と分かったので、自分の送信履歴を日付で検索して並べる。文面を作っただけで送っていないものは「未送」と書く。「送ったつもり」が一番見つけにくい穴でした 10. 注意点 評価そのものを AI にやらせているわけではありません。自己評価を書くための壁打ち相手で、評価するのは人間です 評価基準のドキュメントや業務の話を扱うので、使う AI ツールが社内のルール上問題ないか（入力したデータの扱いなど）は確認した上でやっています おわりに 私は「研ぐ時間」を自分で捻出するのをやめました。10分ですら、自分からは捻出できなかったからです。研ぐ時間は、向こうから来る。来たら雑に書く。覚えておくのは AI の仕事。事実を確かめるのは、自分の仕事。これなら、忙しい週でも回ります。 仕事の PDCA は、仕事をしていれば勝手に回ります。仕事の仕方の PDCA は、仕組みがないと回りません。D はまだ途中ですが、C・A・P が毎週来るようになっただけで、記録の上の自分は4月とは別人になりました。 フル装備でなくてもいいと思います。タスクスケジューラの1行と、記録を1ファイルに溜めること、そして AI のいい人モードを外す指示。この3つだけでも、AI の返答は「感想」から「診断」に変わります。 ここに出てくる行動は、一つずつ見れば薄いものばかりです。期日を自分から言う、環境の調整方法を持ちかける、1人に試してほしいと頼む。それ単体で何かが変わるわけではありません。 それでも、 そういう薄い一つを取りこぼさずに捕まえて、内省して、次の行動に変える。その積み重ねが、自分の糧になる。 私はそう信じています。薄いからこそ、放っておけば当たり前フィルタに消される。 木こりにとっての「刃を研ぐ」は、そういう地味な作業のことだと思っています。

はじめに 楽楽販売を担当している梶です。 運用の知識をAIから引ける（AIが検索して参照できる）ようにして、開発フローの概要設計に運用影響の確認を組み込むところまで来たので、その経緯を書きます。最初から全体を設計していたわけではなく、気づきのたびに一段ずつ足してきた記録です。 運用への影響は、できるだけ設計の段階で拾っておきたいと考えています。サービスを利用するお客様の業務を止めないため、そして、そのための運用を無理なく続けるためです。 「運用のことは、あの人に聞かないと分からない」という状況に心当たりのある開発者や運用担当の方に、読んでいただけたらうれしいです。 はじめに 設計の段階で、運用影響に気づくきっかけが限られていた 段階1：Markdown化とMCPサーバ 段階2：AIに先に引かせる案内文 段階3：概要設計の確認工程 よさそうだが、測りづらい 概要設計で運用影響を確認するスキル 1か月の評価期間 これから おわりに 設計の段階で、運用影響に気づくきっかけが限られていた 楽楽販売は長く提供しているサービスで、運用手順や「この作業ではここに気をつける」といった判断の知識が積み重なっています。その知識は、長く在籍しているメンバーや運用を担当しているメンバーに集まっていました。資料自体は存在していても、どこに何があるかを知っている人は限られていました。 そのため、設計時に運用への影響を考慮できるかどうかは、次のような条件で決まっていました。 運用を担当しているメンバーが、意図的にレビューに入る 開発を担当するメンバーが、似た過去事例を知っている 案件の性質から「運用に聞いておいた方がよさそう」と感じる どれにも当てはまらない案件では、運用影響は設計の段階では表に出にくく、後の工程で運用に詳しいメンバーが拾っていました。気づくのが遅いほど、取れる対応も限られます。設計の段階であればアプリ側で解消できたかもしれないものも、後の工程では、運用手順やインフラのジョブで吸収するほうがその時点では負担が小さい、という判断になることがありました。 また、気にした方がよいと感じていても、何を確認すればよいかの手がかりがないので、質問も具体的にしにくい状態でした。 段階1：Markdown化とMCPサーバ 普段の業務でClaude CodeやCodexを使う中で、「AIがこれだけちゃんとやってくれるなら、AIから引けるようにさえすればなんとかなるんじゃないか」と考えたのが出発点でした。 最初は、手元にあった運用手順やルール、参照表などの資料をClaude CodeでMarkdownに変換し、それを検索できるMCP（Model Context Protocol）サーバを社内に立てました。AIエージェントはMCPサーバを通して文書を検索し、その結果を読んで回答や作業に使います。いわゆるRAG（検索拡張生成）の構成です。 資料は、運用系のものをあまり選別せずにまとめて入れました。試しに聞いてみると関連する文書がきちんと当たり、これだけ当たるなら使えそうだと感じました。 正直に言うと、この時点ではそれ以上のことは考えていませんでした。長期的な計画があったわけではありません。 段階2：AIに先に引かせる案内文 引ける状態はできましたが、それだけでは足りないと考えるようになりました。 運用作業をしているメンバーには、日々の作業の中で「これはどうだったか」と気づくきっかけがあり、分からなければ調べたり聞いたりする発想にもなりやすいと思います。一方で、運用作業に触れる機会が少ない開発メンバーは、ツールが使える状態であっても、「ここで運用ナレッジを引こう」と判断するきっかけがありません。使うかどうかの判断を人に任せたままでは、知らない人には届かないと考えました。 そこで、人が判断しなくてもAIが先にナレッジを引きにいくように、MCPサーバがAIに渡す案内文を書き換えました。以下は実際の案内文を簡略化したものです（名称の一部を変えています）。 書き換え前： Search operations guides, rules, and references. Use search results to identify relevant documents, then read the matched document for executable procedures. 書き換え後： You are connected to the operations knowledge base — the authoritative source for operational procedures (guides), fixed rules, and reference tables. When a question touches any topic below, search here FIRST, then read the matched document, before answering from memory or local code/grep. Topics covered: - guides (procedures): release, rollback, recovery, migration, ... - rules (criteria & conditions): release, approval, security, oss, ... - references (tables & lookup): scheduled-job, maintenance, interface, ... まず、いつ、何より先に調べるかを書きました。書き換え前は検索の使い方を説明しているだけで、どんな話題のときに使うのか、手元の記憶やコード検索とどちらを先に使うのかは書いていませんでした。書き換え後は、目次にある話題に触れたら、記憶やコード検索で答える前にまずここを調べる、と順番まで指定しています。 あわせて、トピックの目次を文書のタグから自動生成して載せました。AIにとって「何が載っているか」が分からないと、引くべき場面を判断できません。目次は文書を追加するたびに自動で更新されるので、手で保守する必要がありません。 この案内文は、AIのセッションが始まるたびにコンテキストへ載ります。利用者が運用ナレッジの存在を知らなくても、関連しそうな話題ならAIの側から先に引きにいくように促せます。 インフラチームから相談を受けたときには、この仕組みが効いていると感じました。相談内容が書かれたスプレッドシートのリンクに「この件相談したい」とだけ添えてClaude Codeに渡したところ、指示していない運用ナレッジも自分から引き、まさに議論したかった論点を挙げてくれました。もっとも、もとの相談が具体的に書かれていたことも大きかったと思います。 段階3：概要設計の確認工程 よさそうだが、測りづらい 「知らなくても引ける」状態に近づき、定性的にはよい取り組みだと言えるようになりました。一方で、成果として示しにくいことに、私自身モヤモヤしていました。AIがタスクの途中で引く仕組みなので、利用者本人も「使った」という実感を持ちにくいのです。 そんなときに、周囲に相談していた中で「開発フローに組み込んではどうか」という話が出ました。使われないツールでは意味がないので、使われる場面が自然に生まれるのを待つのはやめて、確認する場面を工程として置く方向で検討を進めました。 概要設計で運用影響を確認するスキル そこで、概要設計の段階で設計内容と運用ナレッジを突き合わせ、運用影響を洗い出すClaude Codeのスキルを作りました。作る中でつまずいたのが、検索の当て方です。 最初は設計書の差分やDDLをそのまま検索にかけていましたが、当たるべき文書に当たらず「該当なし」になることがありました。設計書の言葉と、運用手順書に書かれている言葉が違うからです。そこで、変更点をいったん「何をしようとしているか」という自然文に起こし、運用文書に書かれていそうな言葉で検索するようにしました。 出力にも決まりを設けました。 該当がなかったときは「運用影響なし」ではなく「現時点で該当なし」と書く。ナレッジに載っている範囲との突き合わせであって、運用全体の網羅的な確認ではないため 出すのはあくまで提案で、採否は設計者が判断する 1か月の評価期間 いきなり必須にはせず、約1か月の評価期間を設けました。合格の基準は結果を見る前に決めて固定し、自分の案件だけでなく、チームメンバーが実際に書いた概要設計で試してもらいました。試用の中では、設計者が見落としていた運用の観点を拾えたケースもありました。 その結果を受けて、2026年9月下旬から、概要設計のチェックリストに「運用への影響を考慮したか」という項目を加えました。運用ナレッジとの突き合わせには、このスキルを使うよう添えています。 これから 今のチェックは、設計の「入口」での確認です。今後は、受入テストや結合テストといった「出口」のタイミングでも運用影響を確認し、その判断の結果を証跡として残せるようにしたいと考えています。 あわせて、運用側として「ここは運用レビューを必須にする」という線引きを定義することも次の課題です。この線が曖昧だと、結局は確認や相談が有識者に集まってしまいます。 おわりに 有識者への依存を減らしたいのは、お客様の業務を止めないための運用を、無理なく続けるためです。 同じように「運用のことはあの人に聞かないと」という状況にいる方は、まずは手元の運用資料をAIから引けるようにしてみてはいかがでしょうか。数本だと当たり外れが分かりにくいのですが、まとめて入れると「使えそうか」の手応えがつかみやすいと思います。 最後までお読みいただき、ありがとうございました。

目次 はじめに サマリ 人間はタスクを完全には並列処理できない 以前にも承認待ちの課題は存在していた 作った仕組みと設計上の工夫 issueの選定条件を明確にする 1回の実行で1 issueだけ扱う 複数のリポジトリを横断してコンテキストを集める まとめ 参考文献 はじめに AIにコードを書いてもらえるようになると、実装は一気に速くなりますが、実装そのものが速くなったからといって、開発全体が速くなるとは限りません。 AIに実装を依頼するには、対応するタスクを選び、必要な資料や前提を集め、実行結果を確認し、次の作業を起動する必要があります。これらの工程に人間の手作業や待ち時間が残っていると、実装速度が上がるほど、今度は実装以外の部分がボトルネックになります。 私自身、SkillsやRules、リポジトリ固有のコンテキストを整えることで、AIによる実装が少しずつ速くなっていることを感じていました。一方で、AIに任せたいタスクがあっても、人間がセッションを立ち上げて指示を出さなければ、作業は始まりません。実装以外の部分には、依然として人間による起動や確認が残っていました。 また、同期的に会話をしながら複数のタスクを切り替えることにも限界を感じていました。AIに任せられる範囲を広げるだけでなく、人間が見るべきものを絞る必要があると考えました。 そこで、Claude Codeのルーティンを使い、実装タスクを定期的に進める仕組みを設計しました。目的は、人間を完全に開発から外すことではなく、人間が判断すべき仕事に集中できるよう、繰り返し作業や待ち時間を減らすことにあります。 この記事では、対象となるissueをどのように選び、必要なコンテキストをどう集め、実装からドラフトPRの作成、レビュー、報告までをどのように自動化したのかを紹介します。 サマリ 今回の課題に対して、 Claude Codeのルーティン を使った仕組みを作りました。 このルーティンは1時間ごとに実行され、対応するissueの選定から、必要なコンテキストの収集、実装、セルフレビュー、ドラフトPRの作成、AIレビュー、実行結果の報告までを行います。1回の実行で扱うissueを1件に絞り、対応方針が明確なものだけを対象にすることで、無人で動かす範囲を限定しました。 *1 一方で、仕様やマージの判断などは人間に残しています。今回の自動化の目的は、人間を開発から外すことではなく、人間の判断が不要な箇所への介入を減らすことです。 人間はタスクを完全には並列処理できない ここでは、AIの実装速度が上がると、なぜ人間がボトルネックになりやすいのかを考えてみます。 人間は複数のタスクを同時に抱えることができます。しかし、それらを同じ瞬間に判断し、行動まで進めることは簡単ではありません。人間が一度に意識して扱える作業情報には限りがあります。一つのタスクを覚えるだけでも、目的、優先度、変更箇所、制約、現在の進捗など、複数の情報を保持する必要があります。複数のタスクを同時に抱えると、すぐに扱う情報が増えていきます。仮に複数のタスクを並列に進められたとしても、すべてのタスクの状況を同じ精度で保持し続けることは難しくなります。 そのため、タスクAに取り組んでいる間、タスクBやタスクCは待ちの状態になります。タスクAを一区切りつけてからタスクBへ移り、さらにタスクCへ移るというように、人間の注意や判断を切り替えながら作業を進めることになります。この状態を、時間の流れに沿って図にすると次のようになります。 タスク切り替えの図 タスクを切り替えるときは、単に別の画面を見るだけではなく、注意を向ける対象も切り替える必要があります。そのため、複数のタスクを並列に進めているように見えても、実際には人間がタスクを切り替えながら、一つずつ処理していることが多くあります。 以前にも承認待ちの課題は存在していた 承認待ちは今回初めて現れた問題ではありません。Auto Modeの登場以前、セッション中には人間の承認を待つ場面がありました。ファイル編集やコマンド実行など、Claude Codeが次のアクションへ進む前に許可を求めることがありました。人間が画面を確認して許可を出せば処理は進みますが、その間はAIも待ち状態になります。 承認待ちをなくすだけであれば、 --dangerously-skip-permissions を使う方法がありますが、このオプションは権限確認を省略し、Claude Codeにすべてのアクションを実行させるためのものです。この方法では安全性の問題が残るため、解決策にはなりません。公式ドキュメントでも、 --dangerously-skip-permissions はすべてのアクションを確認なしで実行するモードであり、隔離されたコンテナや仮想マシンで使うことが推奨されています。 現在のClaude Codeでは、Auto Modeがデフォルトになりました。Auto Modeでは、通常のようにすべてのアクションを人間に確認するのではなく、別のモデルで構成された分類器がツール呼び出しを確認します。危険な操作や環境外への操作などを検出した場合は、処理を止めたり、より安全な方法を選んだり、人間に確認を求めたりします。つまり、Auto Modeは確認をすべて無視するのではなく、AIによるチェックを挟みながら長く実行できるようにする仕組みです。 AIによる判断が安全なものか気になるかもしれませんが、 Anthropicが公開した検証 では、危険なコマンドを人間の手動確認とAuto Modeがどの程度検出できるかを比較し、人間の手動確認が危険なコマンドを検出できた割合は13.6%、Auto Modeは89%だったと報告されています。つまり、Auto Modeは人間の手動確認よりも高い割合で危険なコマンドを検出したとされています。 今回解決したい課題は、Auto Modeが扱っている問題と似ていると考えました。タスクの目的や実行してよい範囲が明確であれば、人間がすべての操作に介入しなくても、AIに作業を任せやすくなります。 そこで、同じ考え方を、セッションの外側にも広げられないかと考えました。どのissueを選び、必要なコンテキストを集め、セッションを起動するかという作業も、条件を定めたうえでAIに任せられるのではないか、という発想です。 作った仕組みと設計上の工夫 今回作った仕組みは、GitHubのissueを起点に、実装からドラフトPRの作成、レビュー、結果の報告までを定期的に進めるルーティンです。 全体の流れは次の図のようになります。 ルーティン全体像の図 issueの選定条件を明確にする 定期実行されるルーティンでは、issueの曖昧さをAIが勝手に補う可能性があります。 そこで、AssigneeやLabelなどの管理情報を、自動実行してよいissueを選ぶための手がかりとして使っています。issue本文の自然言語だけで判断させるのではなく、機械的に確認できる条件を先に置くことで、対象範囲を狭くしています。 1回の実行で1 issueだけ扱う 候補issueが複数あったとしても、1回の実行で着手するのは1件だけにしました。 複数のissueを同時に処理すれば、単純に処理量を増やせます。しかし、無人実行では、どこか一つの判断を誤ったときに複数の変更へ影響が広がります。また、失敗したissueと成功したissueが混ざると、後から原因を確認することも難しくなります。 1回1 issueに制限すると、処理量は減ります。その代わり、どのissueを処理したのか、どこで止まったのか、どの成果物が生成されたのかを追いやすくなります。 また、1回の実行で扱うissueの背景や関連資料などのコンテキストも抑えられるため、AIが参照すべき情報を絞りやすくなります。今回は処理量の最大化よりも、コンテキストを過度に広げず、失敗したときに戻しやすいことを優先しました。 複数のリポジトリを横断してコンテキストを集める issueの本文には、目的、対応範囲、完了条件が分かるように記載していますが、これだけでは実装に必要な情報が足りないことがあります。 現在担当している案件では、実装に必要な情報が複数のリポジトリに分散しています。参照できるリポジトリが限られるとコンテキストが足りず精度が落ちるため、各リポジトリの役割や参照先をまとめたリポジトリを用意し、コンテキスト収集の最初に参照させるようにしました。 まとめ 実際に運用してみると、人間がセッションを起動したり、作業の進捗を確認したりしなくても、手が離れている時間に実装タスクを進められるようになりました。実装を待つ時間や、次の作業を起動する手間が減り、人間は仕様の確認や成果物のレビューなど、判断が必要な作業に集中しやすくなりました。 これにより、仕様がお客様の業務に合っているか、画面が使いやすいかといった、お客様への価値に直結する確認に時間を充てやすくなりました。 今回の取り組みでは、実装にかかる時間が短くなったからこそ、次はその周辺に残っている作業や待ち時間を減らし、開発フロー全体を整えたいと考えました。AIにコードを書かせるだけでなく、AIが継続的に作業できるフローを設計することが重要になると考えています。 参考文献 Claude Code Docs「権限モードを選択する」 Claude by Anthropic「Auto mode is now the default in Claude Code」 Claude Code Docs「ルーティン」 *1 : ここでのセルフレビューは、実装を行ったClaude Codeのセッションが、自身の変更内容を見直す工程です。AIレビューは、ドラフトPRの作成後に別のAIがPRを確認する工程を指します。

■ 目次 はじめに このブログの概要 対象読者と前提知識 1. なぜ、そうなっていたのか？ オンプレミスという前提 Kubernetes導入で得られたもの 残った4つの課題 「境界」と「粒度」 2. 境界をどう引き直したのか？ Namespaceの割り当て先 Tenant境界の導入 セルフサービスでの環境発行 エコシステムのテナント分離 論理的な境界の積み重ね 3. リソースの粒度をどう変えたのか？ k8sリソースの粒度の問題 マニフェスト抽象化OSSの選定 PlatformAppの記述例 拡張性とガードレールの両立 4. 今後の課題 まとめ はじめに こんにちは。SREの gumamon です！ Platform Engineering という言葉をよく聞くようになりました。開発チームが、必要なインフラや開発環境を自分たちで利用できる「セルフサービス」の仕組みを提供する取り組みです。 パブリッククラウドには、そのためのAPIが豊富に用意されています。一方、私たちのKubernetes環境は主にオンプレミス上にあり、同じような仕組みを自分たちで用意する必要がありました。 そこで、社内向けのコンテナ・プラットフォームを開発することにしました。本記事では仮に Platform と呼びます。 オンプレミスという事情から始まったPlatformですが、設計を進める中で直面した課題の多くは、パブリッククラウドでも変わりません。本記事では、その中から特に重要だった設計判断を紹介します。 このブログの概要 この記事では、オンプレミスのKubernetesを複数のプロダクトで利用する社内プラットフォームを題材に、 「境界」と「粒度」をどう引き直したのか を紹介します。 具体的には、以下の内容を扱います。 複数プロダクトを安全に収容するためのテナント境界をどう設計したか 環境発行のセルフサービス化をどう実現したか リソースの抽象化により利用者の認知負荷を削減しつつ、拡張性とガードレールをどう両立したか 「Kubernetesは入れたものの、そこから先に進めない」という状態は、決して珍しくないと思います。私たちがどこに課題を見つけ、どのような考え方で設計を変えていったのかを、順を追って紹介します。 本記事では、Platformを利用するプロダクト（およびその開発チーム）を「テナント(Tenant)」と呼びます。 対象読者と前提知識 社内向けにKubernetes基盤を提供している方 Platform Engineering、特にマルチテナンシーの設計に関心がある方 Kubernetesを導入したものの、組織への横展開が進まないと感じている方 前提知識はNamespace / Deployment / GitOpsの概要が分かる程度で十分です。CapsuleやkroといったOSSについては本文中で都度説明します。 1. なぜ、そうなっていたのか？ オンプレミスという前提 まず、Platformを作る前の状態からご紹介します。 Platform Engineeringの文脈でよく語られる「セルフサービス」は、パブリッククラウドを前提にしていることが多いです。AWSであれば、アカウントを1つ増やす、VPCを1つ切る、といった操作がサービスとして提供されています。開発チームは申請書を書くのではなく、APIを通じて必要な環境を手に入れられます。 一方、私たちのKubernetes環境は主にオンプレミス上にあります。従量課金を避けられるのは大きな利点ですが、「アカウントを増やす」に相当する仕組みは当然ながら存在しません。 それでも同じような体験に近づけたいと考え、一部の商材でKubernetesを導入し、そこから社内への横展開を進めていました。 Kubernetes導入で得られたもの Kubernetesの導入によって、得られたものは確かにありました。 コンテナ化 によって、アプリケーションとインフラが疎結合になった GitOps によって、インフラ構成の変更がGitのマージで完結するようになった 結果として、マイナーリリースは開発チーム主導で回せるようになり、開発速度も向上しました。 しかし、これを商材横断で広げようとすると、別の問題が見えてきました。 残った4つの課題 ① 認知負荷が高く、横展開が進まない Kubernetesそのものに加えて、Argo CD、Vault、Grafanaといったエコシステムの知識が必要になります。 1つのWebアプリを本番品質で動かすだけでも、Deployment、Service、HTTPRoute、HPA、PodDisruptionBudget、Secretなど、多数のリソースを組み合わせなければなりません。 新たに利用する開発チームに「まずこれを覚えてください」と言える分量ではありませんでした。 ② 環境発行がセルフサービスになっていない 開発チームが検証用の環境を必要とした場合、インフラチームへクラスタ構築を依頼する必要がありました。 そのため、環境を必要としてから実際に利用できるまで、数日から数週間のリードタイムが発生していました。 ③ クラスタが増え続ける 環境を増やす手段がクラスタを増やすことだったため、クラスタは「商材 × 環境」の数だけ増えていきました。 Kubernetesはクラスタごとに管理用のコンポーネント一式を必要とします。さらに、初期構築、可観測性のセットアップ、半年に一度のKubernetesアップデート、リソース不足に伴う作り直しなどもクラスタごとに発生します。 結果として、クラスタの増加に比例して運用コストも積み上がっていました。 ④ テナントの境界が曖昧 Kubernetesには、標準機能として明確な「テナント」の概念がありません。 各商材のKubernetesクラスタは分離されていた一方、Argo CD、Vault、Grafanaなどのエコシステムは複数商材で共同利用していました。 そのため商材間のシステム境界が曖昧で、あるチームの操作が他チームへ影響し得る状態でした。安全に権限を委譲することが難しく、インフラチームによる管理が必要となっていました。 「境界」と「粒度」 一見すると別々に見える4つの問題ですが、整理すると2つの問題に集約できました。 1つは、 「境界」 です。 商材や環境をどの単位で分離し、どこまでを開発チーム自身で管理できるのか。その境界が適切に設けられていなかったことが、環境発行やクラスタ増加、権限移譲の問題につながっていました。 もう1つは、 「粒度」 です。 Kubernetesでは、1つのアプリを動かすために多数のリソースを組み合わせる必要があります。この粒度の細かさが、利用者に求める知識や設定量を増やしていました。 そこで私たちは、Kubernetesそのものを置き換えるのではなく、この 「境界」と「粒度」を引き直す ことにしました。 まずは「境界」から見ていきます。 2. 境界をどう引き直したのか？ Namespaceの割り当て先 最初に整理したのは、Kubernetes上の境界です。 私たちが必要としていた境界は、大きく3つありました。 Tenant ：組織・プロダクトの境界 Env ：Prod、Staging、Developなどの用途別の境界 App ：Web、Backend、Batch、DBなどのアプリケーションの境界 従来、これらは次のように割り当てられていました。 従来 Tenant 仕組みなし（運用ルール依存） Env Kubernetesクラスタ（要インフラ作業） App Argo CD Application ＋ Namespace 境界(Before) ここで着目したのが、 Namespaceの使い方 です。 従来は、Web用のNamespace、Batch用のNamespaceというように、NamespaceをAppの分離に使っていました。 一見すると自然な使い方ですが、この時点でNamespaceというKubernetesの論理的な分離単位をAppのために使っています。そのためEnvを増やそうとすると、残された手段はクラスタそのものを増やすことでした。 「環境発行に数週間かかる」「クラスタが増え続ける」という課題は、症状だけを見れば運用の問題です。しかし、その原因は 境界の割り当て にありました。 そこで私たちが下した判断は、以下のとおりです。 Appの分離からNamespaceを解放し、Envの境界に再割り当てする。 Appの分離はArgo CDのApplicationが担えるため、NamespaceはEnvに譲ります。 すると、残るのがTenantの境界です。 Tenant境界の導入 KubernetesにはTenantに相当する標準の境界がありません。そこで、この層を補うために Capsule を採用しました。 CapsuleはNamespaceを束ねて1つのTenantとして扱い、その管理をテナントオーナーに移譲できるKubernetesの拡張です。 Tenantの実装方式としては、他にvCluster、マルチクラスタ、Kubernetes標準のRBACのみ、という選択肢も検討しました。いずれもリソース消費や運用負荷、テナント識別の一元管理といった観点で課題があったため、追加のコントロールプレーンを持たないCapsuleを選んでいます。 Capsuleはadmission Webhookとして動作するため、テナント利用者は普段どおり kubectl を使うだけで済みます。 Tenantは以下のように定義します。 apiVersion : capsule.clastix.io/v1beta2 kind : Tenant metadata : name : product-a spec : # Namespace名が必ず "product-a-" で始まることを強制する forceTenantPrefix : true namespaceOptions : quota : 10 # このテナントが作れるNamespaceの上限 owners : - name : product-a kind : Group resourceQuotas : scope : Tenant # テナント全体でCPU/メモリ/ストレージの上限を持つ 結果として、境界は以下のように変わりました。 従来 Platform Tenant 仕組みなし Capsule （サービスとして払い出し） Env クラスタ単位（要インフラ作業） Namespace単位（セルフサービス可） App Argo CD Application ＋ Namespace Argo CD Application 境界(After) forceTenantPrefix によってNamespace名が必ずテナント名で始まると保証されるため、監視の設定やネットワークの制御を、テナントがNamespaceを増やしても追記の要らない形で書けるようになりました。 命名規則を強制することが、後段の自動化の前提になっています。 セルフサービスでの環境発行 境界を引き直した結果、環境の発行はテナント側リポジトリの設定ファイルに1行追加するPull Requestになりました。 # settings/namespace/values/platform-dev-001.yaml namespaces : - namespace : product-a-dev-001 - namespace : product-a-dev-002 # ← この1行を追加するだけ GitHub Actionsのフォームから実行するとこのPull Requestが自動生成され、マージすればArgo CDがNamespaceを作成します。 数週間かかっていた環境発行が、数分で完了するようになりました。 テナントにはCPU・メモリ・ストレージの上限があり、その範囲内でやりくりする形になります。上限の緩和はプラットフォーム管理者側の設定変更で対応できます。 エコシステムのテナント分離 ここまでがKubernetes側の話です。 しかし実際に手を動かしてみると、 境界は1つ引いて終わりではありませんでした。 Capsuleが守ってくれるのは、Kubernetes APIに到達したあとの世界だけです。Argo CDの画面の中や、Vaultのシークレット一覧、Grafanaのダッシュボードには届きません。 KubernetesにTenantという境界を導入したのであれば、同じ境界を周辺のコンポーネントにも伝える必要があります。 結果として、レイヤーごとに分離の方式が異なる構成になりました。 レイヤー 分離の方式 GitOps (Argo CD) テナントごとのAppProject＋GitHub TeamsによるRBAC Kubernetes Capsuleの Tenant （admission Webhook） 認証 テナント名を持つクライアント証明書 シークレット (Vault) テナントごとのSecret Engine ログ (Loki) テナントIDによる振り分け メトリクス テナントごとのアカウントID トレース (Tempo) テナントIDによる振り分け 外部公開 (Gateway) テナントごとのGateway ネットワーク NetworkPolicyによるテナント間通信の遮断 エコシステムのテナント分離設計 分離の方式がレイヤーごとに異なるのは、各プロダクトが持つマルチテナント機能の実装差がそのまま表れているためです。 すべてを同じ仕組みで分離することはできず、レイヤーごとに個別の設計が必要でした。 ただし、開発チームから見た場合、いずれのエコシステムの利用も一貫した体験となるよう工夫をしてあります。 ログインは全てGithubのOAuth認証 いずれのエコシステム(UI)にログインした場合も、自身の所属するプロダクトのリソース以外が見えない状態 1章で挙げた「テナントの境界が曖昧」という課題は、ここで解消しました。 論理的な境界の積み重ね ここまでの話を一言でまとめると、Platformの分離は物理的な分離ではなく、 論理的な境界をレイヤーごとに積み重ねたもの です。 クラスタは1つのまま、その上にCapsule、Argo CDのAppProject、VaultのSecret Engine、NetworkPolicyなどを重ねています。 当然ながら万能ではありません。 ハードウェアレベルで分けたい要件があるのであれば、素直にクラスタを分けるべきです。私たちも「複数商材を1クラスタに収めることは推奨するが、強制はしない」という立場を取っています。 分離の強さと運用効率のトレードオフは、要件に応じて評価する必要があります。 3. リソースの粒度をどう変えたのか？ k8sリソースの粒度の問題 ここまでが「境界」の話です。 次は、もう1つの課題である「粒度」を見ていきます。1章で挙げた「認知負荷が高く、横展開が進まない」という課題に対する打ち手です。 Kubernetesのリソースは、レゴでいえば一番小さい基本ブロックに相当します。 自由度は極めて高い反面、AWSのECSタスク定義1つで済むことを表現するのに、Deployment、Service、HTTPRoute、PodDisruptionBudget、ServiceAccount、ConfigMap、Secretなど、多数のブロックを自分で組み合わせる必要があります。 Helm Chartにすると、テンプレートは十数個、YAMLは数百行という規模になり、その大半がプロダクト間でコピー＆ペーストされていました。 これが「認知負荷が高く、横展開が進まない」という課題の正体でした。 Kubernetesの細かいリソースを毎回利用者が組み立てるのではなく、社内でよく使う標準構成を、より大きな単位のブロックとして提供することにしました。 リソースの抽象化(Before / After) マニフェスト抽象化OSSの選定 マニフェストを抽象化するOSSとして、 kro （kubernetes-sigs）と KubeVela （CNCF Incubating）を比較し、kroを採用しました。 決め手はテンプレートの記述方式です。 kroのテンプレートはYAMLで、中身はほぼ素のKubernetesマニフェストです。一方のKubeVelaはCUEという独自言語と、Component / Trait / Policy / Workflow という独自概念の習得が必要でした。 ほぼ素のマニフェストで書けるということは、 基盤を作る側にとっても使う側にとっても学習コストが低く、同時に将来別の方式へ移す際のコストも低い ということです。 v0.x系の若いOSSを基盤の中核に据える以上、後戻りできる構成であることを重視しました。 PlatformAppの記述例 こうして生まれたのが PlatformApp というカスタムリソースです。APIなど、常時起動が必要なアプリケーションを簡単にデプロイするために使います。 開発チームが書くのは、以下のような定義です。 image : tag : 1.0.0 platformApp : configMap : data : GREETING : "こんにちは" deployment : replicas : 1 container : resources : requests : { cpu : 10m, memory : 32Mi } limits : { cpu : 20m, memory : 64Mi } service : port : 8080 targetPort : 8080 httpRoute : enabled : true hostnames : - product-a-dev-001.example.internal rules : - matches : - path : { type : PathPrefix, value : / } これで生成されるのは、Deployment / Service / HTTPRoute / ServiceAccount / PodDisruptionBudget / ConfigMap / Secret（Vault連携）の 7種類 です。 Probeやセキュリティ設定などにはプラットフォーム側の既定値が入るため、必須項目はコンテナイメージの指定だけです。既定のままでよければ、定義は十数行に収まります。 また、単に記述量を減らすだけでなく、 Kubernetesに詳しくない利用者でも安全に使えること を重視しています。 たとえばPodの requests / limits は必須とし、未指定の場合は既定値を設定します。これにより BestEffort QoSのPodを作らせず、共有クラスタで他のワークロードに影響を与えにくい状態を既定にしています。 同時に、CPUやメモリを見積もることを標準的な運用として意識してもらう狙いもあります。 ほかにも、利用者が意識しなくても正しく動作するための仕組みをいくつか組み込んでいますが、長くなるため本記事では割愛します。 設定しなくても安全に、正しく動く状態を既定にする ことが、PlatformAppの重要な役割だと考えています。 拡張性とガードレールの両立 抽象化を設計するうえで意識したのが、 拡張性とガードレールを両立すること です。 PlatformApp は標準的なユースケースを簡単に扱うための抽象化ですが、プラットフォーム側がすべての要件を事前に想定することはできません。 そこで、アプリケーション設計における「 修正には閉じ、拡張には開く 」という考え方を参考に、標準構成を壊さずに利用者側で拡張できる構造にしました。 ① PlatformXxx自体に柔軟性を持たせる PlatformAppでは、内包する多くのリソースの設定値を固定値ではなく既定値で埋めています。 これにより、利用者は柔軟なリソース設定が可能となっています。 なお、ここまで説明をしてきた PlatformAppは、ユースケースの一つでしかありません。 DBのデプロイを担う PlatformPg があり、非同期JobWorkerとして機能する PlatformWorker を開発予定です。 ② PlatformAppの外にも拡張できる デプロイの仕組みであるArgo CDのApplicationSetは、リポジトリ配下のディレクトリをHelm Chartとしてデプロイしているだけです。 PlatformApp はそのChartで利用できる選択肢の1つに過ぎないため、要件に合わなければ独自のHelm Chartや素のDeploymentを利用できます。 ただし、何でも自由にデプロイできるわけではありません。たとえばCluster Scopeのリソースなど、Tenantに与えられた権限を超える操作はCapsuleによってブロックされます。 つまり、 抽象化の外には出られるが、プラットフォームのガードレールの外には出られない 構造です。 ③ 段階的に使いこなせる 利用者が必要に応じて一段ずつ深いレイヤーへ進めるよう、次のような段階を想定しています。 Level 1： PlatformApp の標準構成 Level 2： PlatformApp のカスタム構成 Level 3：独自のHelm Chart Level 4：改善をプラットフォーム側に還元する 抽象化によってKubernetesを知らなくても使える入口を作りつつ、必要になったときにその内側へ進める余地は残しています。 利用者を抽象化の中に閉じ込めるのではなく、 安全性を保ちながら段階的に拡張できること を重視しました。 学習コストの「崖」を「階段」に 4. 今後の課題 Platformはまだ道半ばです。例えば以下のような課題が残っています。 テナント数に比例する運用負荷 ：テナントが増えれば、テナント単位で持つコンポーネントも増えます。テナントを増やす作業そのものの自動化が次の課題です。 初期の設計判断の修正 ：ここまで「粒度」を再定義するためにkroを採用したとお話ししてきましたが、Helm Chartの提供でもできるのでは？という議論を行っています。kroによる抽象化ではPlatformにデプロイするまで展開されるリソースの構成が分からないため、手元で helm template できる方が利用しやすいのでは、と思案中です。 まとめ 今回は、オンプレミスのKubernetes上に社内向けプラットフォームを構築するにあたり、「境界」と「粒度」を引き直した設計を紹介しました。 境界 ：NamespaceをEnvに割り当て、Capsuleを使ってTenantの境界を追加 粒度 ：複数のKubernetesリソースを PlatformApp として抽象化 これにより、クラスタを増やさずに環境をセルフサービスで発行でき、開発チームが扱うKubernetesリソースも減らすことができるようになりました。 一方で、テナント追加時の運用負荷や、kroによる抽象化が適切かどうかなど、まだ改善すべき点も残っています。 この記事が、Kubernetes基盤を横展開していく際の設計を考える一例になれば幸いです。 以上、最後までお読み頂きありがとうございました！

今回は、楽楽勤怠に組み込まれた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ネイティブ」の両方を大切にしながら、地に足のついた検証を重ねる開発組織を、一緒に作っていく仲間を募集しています。ご興味を持っていただけた方は、ぜひ採用ページもチェックしてみてください。 最後までお読みいただきありがとうございました！