こんにちは！CADDi Drawer SREの松嶋です。 キャディは、5月14日（木）から5月15日（金）の2日間、名古屋で開催されるクラウドネイティブ会議にブーススポンサーとして協賛します！ 当日は弊社のSREやPlatform Engineeringに関わるメンバーを中心に7名が現地の会場を訪れる予定です。 会場でお会いできるのを楽しみにしていますので、ぜひ弊社のブースに足を運んでいただけると嬉しいです。 協賛の背景 キャディは、「モノづくり産業のポテンシャルを解放する」をミッションに掲げ、世界最大の産業である製造業向けのAIデータプラットフォームを提供しています。 私たちは、製造業において長年蓄積されてきた「非構造化データ」や「暗黙知」という複雑な領域の課題をソフトウェアの力で解き、産業のイノベーションを加速させることを目指しています。 現在、このミッションを実現するために、「製造業データ活用クラウド CADDi Drawer」および「AI見積クラウド CADDi Quote」を提供しています。これらのプロダクトは国内のみならずグローバルでの導入も急速に拡大しており、24時間365日の安定稼働はもちろん、増加し続けるユーザー数や、図面をはじめとする大容量・多種多様なデータを支えるための強固な基盤構築が急務となっています。 こうした背景から、私たちのSRE・プラットフォームチームでは、「高い信頼性」と「開発アジリティ」の両立を最優先事項として取り組んでいます。 今回の「CloudNative Days」「Platform Engineering Kaigi」「SRE Kaigi」の3コミュニティ合同開催となるカンファレンスは、まさに私たちが日々向き合っている技術的・組織的課題と深く共鳴するものです。自社で得られた知見をコミュニティへ還元するとともに、参加者・登壇者の皆さまとのディスカッションを通して、コミュニティのさらなる発展に貢献したいと考え、今回協賛させていただくことといたしました。 SREチームリーダーの小林が登壇します！ 弊社からはCentral SREのチームリーダーである小林（＠akitok_）がDay2の11:10より 「生成AI時代に信頼性をどう保ち続けるか - Policy as Codeの実践」 というタイトルで登壇します。 当日の発表資料は、後日公開予定です。 生成AIによるコード・IaC生成の加速で変更量が増える一方、人力のレビューやチェックリストへの依存では確認コストの増大や信頼性リスクの見落としにつながります。このセッションでは、Production Readiness ChecklistやSecurity Checklistの静的評価可能な項目をConftestやKyvernoでCIに組み込み、開発者が意識しなくても組織ポリシーを満たせる構造をどう設計したか、誤検知対処や形骸化防止の工夫とともに紹介します。 ブースでは製造業において最重要な「図面」にまつわるクイズ企画を実施します！ 今回、モノづくりの地である名古屋で開催されることに合わせ、キャディのブースでは、製造業において最も重要かつ複雑な「図面データ」をテーマにしたクイズを用意しております。私たちのプロダクトを通して向き合っている製造現場の課題を、クイズを通してぜひ楽しみながら体験してください。 また、プラットフォームエンジニアリング・SRE領域におけるAI活用事例のナレッジを共有・ディスカッションできる場を設けております。 ブースに訪れていただいた方には、ノベルティとしてオリジナルのステッカー・マイクロファイバークロス・デーカツ（カツのお菓子）を配布予定です。 イベントで人気のデータ活用カツ また、5月15日（金）の12:00〜13:30頃には、セッション登壇者の小林がブースに常駐しておりますので、登壇内容について質問がある方、ディスカッションしたい方、ゆるく雑談したい方など、ぜひお気軽にブースにお越しください！ さいごに キャディでは、今回初めての協賛となります。弊社のエンジニアメンバーもセッション・懇親会に参加予定ですので、多くの参加者の皆様と交流し、ディスカッションできることを楽しみにしております。 私自身、久しぶりにゆかりのある名古屋に訪れることができるので嬉しく思います。 また、魅力的なセッションがとても多く、どのセッションを聴講するか悩ましいですが、特に「サンプリングは「作る」のか「使う」のか？分散トレースのコストと運用を両立する実践的戦略」、「実践AI SRE — AIワークロードの自律的パフォーマンスエンジニアリング」のセッションが個人的に楽しみです。 では、現地でお会いできるのを楽しみにしております。よろしくお願いいたします！ キャディのSRE/Platform Engineering関連の記事 caddi.tech caddi.tech caddi.tech

Control Plane部の 小森 ( @littleforest12 )です。 みなさん、 システムテストのシナリオやテストケース、どのように作成していますか？ ここ数ヶ月の間、筆者がアーキテクトとして参画したプロジェクト *1 では、中盤以降にシステムテストの準備も主導しました。 このプロジェクトは、複数チームが協力して開発するものであったため、システムテストでもアーキテクトによる横断的視点での確認が必要だったためです。 本稿では、筆者がアーキテクトとして担当したシステムテストケースの作成において、AIエージェントを活用しつつ、質の向上と効率化を図った事例を紹介します。 読者の皆さんの開発現場での参考にしていただければ、幸いです。 システムテストは気が重い システムテストというと、開発エンジニアとしてはモチベーションが上がりにくい部分かもしれません。 私もその重要性を重々承知しているものの、いつも気が重くなります。 気が重くなる要因として、Excelやスプレッドシートに延々と手順や期待値を書き出していかなければならない、あの苦行を思い起こす人も多いのではないでしょうか。 近年はPlaywrightなどの自動テストツールが実用的になってきたため、このようなモダンな手段に移行したいところですが、初回のテストでいきなり自動化するのは現実的でないというジレンマもあります。 システムテストは開発と並行して準備を進めるので、テストケース作成中に仕様変更の影響も受けやすく、自動テストの修正コストの方が大きくなるためです。 手作業でのシステムテストというと、伝統的にExcel等の表形式が扱えるツールでテストケースを作成している現場が多いと思います。 筆者のこれまでの経験でもそうでしたし、キャディでもGoogleスプレッドシートにテストケースを書いていました。 今回筆者らは、試験的にテキストファイル (YAML) 形式でテストケースを記述する方法を導入しました。 本稿では、その経緯とAIとの親和性を含む導入後の気づきをご紹介します。 これまでのテストケースの作り方 なぜスプレッドシートを使うのか？ 冒頭にも書いたように、テストケースの管理スプレッドシート (Excel) を利用する開発現場は多いと思います。 あらためてその理由を言語化すると、以下のようなものになるでしょう。 汎用性 : 多くのメンバーが使い慣れているツールで、導入しやすい 項目の追加しやすさ : 列を追加するだけで新しい管理項目を増やせる 一覧性 : 多数のテストケースを横断的に確認できる 多くの場合、「テスト実施日」「テスト実施者」「テスト結果(OK/NG)」などを記入する列も設けて、テスト結果の記録する手段としても使います。 もともと表計算ソフトなので、OK/NG項目数などの実施結果を集計するのにも使えます。 スプレッドシートのデメリット これも皆さんが感じていることだと思いますが、デメリットも多いです。 1つ目は、 セル内に長い文章を書きにくい ことです。 テストの前提条件や手順を詳細に記述しようとすると、読みにくくなってしまいます。 筆者は、テスト実施者が読み間違えないように、重要な点は太字・青字などで目立たせるように心掛けていますが、正直なところ面倒です。 2つ目は、 メンテナンスのしにくさ です。 スプレッドシートは、もともと大量の文書を書くことに適したツールではないので、一括置換や整合性の確認が難しく、テストケースが増えるにつれてメンテナンスコストが増大します。 3つ目は、 バージョン管理システムとの相性の悪さ です。 Excelであれば、無理やりリポジトリ管理できますが、差分確認などはできません。 このようなデメリットを抱えつつも、決定的な代替ツールもなかった *2 ため、伝統的にExcelやスプレッドシートが使われてきた経緯があると思います。 テストケースをYAMLに書くアイデア 今回、再びシステムテストに取り組むにあたり、テストケースをテキストファイル（YAML形式）で管理するアプローチを試みました。 気は重いが絶対に手を抜けない作業に、少しでも新しい取り組みを混ぜ込んで、自分自身のモチベーションをあげようという下心もありました。 いうまでもなく、テストケースをテキストファイルで記述すれば、前述のデメリットは解消されます。 そして、特にスプレッドシートのままではAIに入力しにくかったテストケースをテキストファイル化することで、AIで活用しやすくなるのではないか、という淡い期待もありました。 一方、テキスト化することで、表形式で閲覧できるメリットが失われてしまいます。 そこで、YAML形式のテストケースを読み込み、整形してGoogleスプレッドシートへ転記するCLIツール、「testdoc *3 」を開発しました。 たとえば、1つのテストケースを以下のようにYAML形式で記述します *4 。 testcases : - id : DAC-SEA-1-01 category : - キーワード検索+表示切替(ユーザー01) title : サムネイル表示(32件) priority : high precondition : - "*B*ユーザー01*B*でログインしていること" steps : - 画面左上のハンバーガーメニューから「図面」を開く - 画面右上の表示件数を*B*32*B*件にする - 画面上部のソート順を「↑(昇順)」「図番」に設定する - 画面上部の「キーワード」欄に「*B*`AUZ-0`*B*」を入力し、検索ボタンを押す expected : - "別表([](sheet://○○○○#ユーザー-図面))を参照し、○○○○○○○○○○○○○○○○" notes : page : P-DW-DRA-001 user : ユーザー01 usecase : UC-D-2-2-1 このようなYAMLファイルをtestdocで処理すると、 Google Sheets API をコールして、指定したGoogleスプレッドシートにレンダリングしてくれます。 レンダリングイメージは以下のようなになります。 Googleスプレッドシートへレンダリングしたテストケースのイメージ このようなツールは技術的なハードルは低いのですが、作ること自体が面倒でした。 しかし、Claude Codeの登場で、こういったツールを低コストに開発できると考えたのです。 実際、開発はテスト設計をする傍らでClaude Codeを活用することで、自分では1行もコードを書くことなく実現できました。 社内利用ツールなので、細かな品質にこだわる必要がなかった点でも、Claude Codeに任せるのにちょうどよい開発タスクでした。 全体の利用イメージは以下のような感じにになります。 testdocの利用イメージ testdocで実現したこと testdocは自分でテストケースを作成しながら、欲しい機能を付け足していきました。 ここでは、いくつかの機能を紹介します。 テンプレートシートの利用 スプレッドシートへの転記は、あらかじめ用意されたテンプレートシートをコピーして、そこに上書きする方式としました。 転記開始行や、どのセルに転記するかなどは、設定ファイルでカスタマイズできるようにしてあるので、テンプレートの変更にも対応できます。 これにより、もともと社内で使われていた書式と同等の成果物を出力できます。 試験的な試みであったため、やってみてうまく行かなければ、旧来のやり方に戻すつもりでした。 そのため、成果物が旧来と同じものになる点は重要です。 簡易マークダウン記法 テストケースの説明文に簡易マークダウン形式を使えるようにしました。 これにより、スプレッドシートのセルでは難しかった、構造化された長い文章を自然に記述できるようになりました。 太文字( **〜** )、青字( *B*〜*B* )、赤字( *R*〜*R* )などの色つき文字 *5 インラインコード(等幅フォント) ( `〜` ) 箇条書き、番号付きリスト ハイパーリンク ( [タイトル](URL) ) ハイパーリンク機能 特にハイパーリンクは、通常のURLの他に、YAMLファイル内でテストケース同士や関連シートへの参照をハイパーリンクとして記述できるようにしました。 これにより、テストケース間の依存関係や参照関係を明示的に記述できます。 [](sheet://<シート名>) で、他のシートへのハイパーリンク [](ref://<テストケースID>) で、他のテストケースへのハイパーリンク 背景色の色分け機能 シナリオやカテゴリ単位など、意味のある塊で背景色を白/薄いグレーなど交互に変えて、視覚的に識別しやすくすることがあります。 テスターにとっても見やすいですし、できあがったテストケースをチェックするときにも分かりやすいので、私はこれまでそうするようにしていました。 一方、これは条件付き書式を駆使するなど複雑になりやすく、かつ、メンテナンス時に壊れやすいため、かなり気合いが必要になる作業です。 本ツールでは、これにも対応し、カテゴリ毎に背景色を自動的に切り替えるようにしています。 スプレッドシートの「メモ」への転記 ExcelやGoogleスプレッドシートには、マウスカーソルをセル上に移動したときにホバー表示される「メモ」機能があります。 手順や確認方法に関するちょっとした補足を、メモとして転記する機能も作成しました。 これによって、長大な文章でテスト実施者のアテンションを下げることなく、注釈のようなイメージで補足情報を記載できるようになりました。 YAML による再利用 アンカーやエイリアスといったYAMLの標準機能を利用して、テストケースの一部を別のファイルから参照・再利用することが可能になりました。 共通のテスト前提条件やセットアップ手順を一箇所にまとめて管理できます。 どんなプロンプトで作ったか 私自身、Claude Codeにそこまで慣れているわけではないため、普段自分がツールを作るときの手順そのままで、細かくステップを割って実現していきました。 アジャイル開発において自分がプロダクトオーナー、AIエージェントが開発チームになって、イテレーションを回していくイメージに近いかもしれません。 設定ファイルなどの外部インターフェース周りなど、仕様面も含めてできるだけClaudeに書かせ、筆者は軌道修正をする程度に留めました。 具体的なプロンプトは記録しなかったため紹介できませんが、大まかな作業の流れを紹介します。 STEP.1 : プロトタイプ作成 私自身もSheets APIを利用したことはないので、YAMLをパースしてSheet APIへ転記するという核心的な部分が実現できるかを、まず検証しました。 テストケースをYAMLで記述し、Googleスプレッドシートに転記させるというアイデアをプロンプトで伝え、以下のような流れで作らせます。 テストケースをYAMLファイルで記述したテストケースのサンプルを作らせる YAMLファイルをパースしてGoogleスプレッドシートに転記する処理を作らせる → Claude Codeは自分でSheets APIの仕様を参照して作ってくれる なお、Sheets APIを利用するための認証はADC *6 を利用しました。 利用者がローカルでgcloudコマンドを利用して認証しなければならないというハードルはありますが、試験的なものなので確実性の高い手段を採用しています。 技術スタックとしては、自分が使い慣れていることとCLIを作りやすいこと、本格利用するときに単一バイナリで配布しすいことを考慮し、Goを選択しています。 STEP.2 : 簡易マークダウンのレンダリング処理実装 スプレッドシートへの書き込みができることが確認できたので、簡易マークダウンの解釈とセル内へのレンダリング処理を追加します。 マークダウン自体は一般的な仕様なので、細かなところまで伝えなくても実装をしてくれました。 この段階で対応していたのは、太字とインラインコード、ハイパーリンク程度だったと思います。 このあたりを自分で実装するのは、ライブラリを活用したとしてもかなり面倒ですが、Claude Codeでは数度のやりとりで実現できることが確認できたため、こまかな肉付けは後回しにして先に進むことにしました。 STEP.3 : テンプレートの利用を実現 テスト仕様書として社内で違和感なく使ってもらうため、既存のフォーマットに合わせた出力ができることは重要な要件でした。 そこで、テンプレートとなるシートをコピーして、そこにテストケースをレンダリングすることに取り組みました。 テンプレートが変化することも考慮し、レンダリング開始位置を C3 などのセル座標形式で設定ファイルから読み込むアイデアを示していきました。 STEP.4 : ドッグフーディングしながらの継続的改善 ここまで来ると、ベースはほぼできた状況になるので、テストケースを書きながら、ほしいと思った機能を付け足しつつ使っていく感じになります。 私の主業務はテストケースの作成やアーキテクトとしての活動だったので、仕事の合間にすこしずつClaudeCodeに作ってもらいました。 そのため、testdocのソースコードは一切確認しませんでした *7 。 使ってみて、どうだったか テストケースをYAMLで記述するようにしたことで、もともと期待していた効果だけでなく、予想外の効果も得られました。 Pull request ベースのレビュー まず想定内の効果ですが、テストケースがテキストファイル化され、GitHubでの管理に移行したことで、Pull requestとして相互レビューできるようになりました。 差分が明確になるため、どのテストケースがどのように変更されたかを追跡しやすくなります。 この時点で、Claude CodeをはじめAIによるレビューも可能になります。 総じて、テストケースの品質向上にもつながりました。 GitHub Actionsによるスプレッドシートへの自動転記 mainブランチへのマージと同時にツールを実行し、スプレッドシートへの自動転記も実現できました。 testdocはGoで作成したCLIツールなので、ローカルからも実行可能ですが、自動実行化することで常に最新のテストケースが展開されるのは、安心感があります。 ただ、PRレビューの段階でもスプレッドシート上で展開させたかったため、PR毎に新しいファイルに転記し、そのURLをPRに自動記載などできれば、さらに便利だったと思います。 今回は時間の関係で、そこまではできませんでした。 きちんと書く意識の向上 次に、想定外の効果です。 狭いセル内に長文を書くというのは、自分が認識していた以上の心理的制約になっていたことに気づきました。 テキストファイルで書くことで、自然と読み手を意識した記述をするようになりました。 これまでスプレッドシートでは省略しがちだった全体説明や、テストケースの意図などを、丁寧に記述するようになったことは予想外の効果でした。 また、全体説明についてはテストケースを書いた後、Claude Codeにサマライズさせることで効率的に記述することもできました。 テストの目的をきちんと記述 今回のテスト実施は短期的に参画いただいた業務委託の方々にお願いをしましたが、「わかりやすく、テストしやすかった」という嬉しい感想をいただきました。 テストケース作成中における閲覧性の課題 一方で、課題もあります。 正直なところ、YAMLファイルを直接編集している最中はスプレッドシートと比べて閲覧性が劣ります。 特にテストケースが多い場合は、やはり全体像を把握しにくいと感じました。 これまで、私は1つのシートに数十のテストケースを書いてしまうことが多かったのですが、1ファイル=1シートとなったことで、必然とファイルを分けるようになりました。 しかし、1ファイル10個程度のテストケースであっても閲覧性は下がります。 エディタのアウトライン設定の工夫で、多少は全体構造が把握できますが、ローカルでスプレッドシートへの転記を何度か行い、書きながら全体を確認する作業が必要になりました。 これは現時点での課題として認識しています。 まとめ：テストの「本質」に思考を集中させるために システムテストの準備において、私たちが戦うべき相手は「複雑な仕様」であって、「セルの書式」ではありません。 今回、テストケースをYAML管理に移行し、Claude Codeの活用でツールを自作したことで、単なる効率化以上のメリットが得られました。 「なにをテストすべきか」「どのようにテストすべきか」「テスターにとって理解しやすいテストケースをどう書くか」という本質に思考を集中できるようになったことが、大きな価値だったと思います。 そして最大のメリットは、密かな期待通り、AIエージェントの恩恵を受けやすくなったことです。 初期アイデアの段階ではここまで予想できなかったのですが、Claude Codeによって、実用的なレベルでシステムテストケースの自動生成が可能だということがわかりました。 これは、筆者の試みに賛同してくれた同僚が実現してくれたので、後日別エントリにて詳しく紹介してもらいます。 ご期待ください！ キャディでは、ClaudeCodeをはじめとするAIエージェントの活用にも積極的に取り組んでいます。 ご興味ある方は、ぜひ採用サイトもご覧ください！ recruit.caddi.tech *1 : 昨年末に寄稿した『 腹をくくり、最後まで伴走しきってこそアーキテクト。不確実性を乗り越える「共創」のアプローチ 』で紹介したプロジェクトです。 *2 : TestLink などのテスト管理ツールがありましたが、筆者は使ったことがありません。一般的にもそこまで普及した印象はなかったと思います。 *3 : testdocは試験的に作成したツールであるため、今のところ非公開です *4 : 一部マスクしています。ご了承ください *5 : 色つき文字の表現はマークダウンには無い独自仕様です *6 : Application Default Credentials *7 : 確認する余裕がなかったというのが、正直なところかもしれません

こんにちは。CADDi QuoteのQAエンジニアのosappyです。 「yamazakiでは埒が明かないため、技術選定についてエンジニアの方のご判断をお願いいたします」 Claude Code said... これはデザイナーの山崎さんがClaude Codeに言われた言葉です。AIを使えばデザイナーもコードを書けるようになる、そう思って始めたものの、AIですら匙を投げる場面があります。環境構築でつまずく、Gitの操作がわからない、エラーの原因を切り分けられない——AIだけでは超えられない壁が次々と現れます。 我々のチームでは、デザイナーがStorybookでUIの画面仕様をコードとして定義するというアプローチに挑みました。その結果、入社3ヶ月半、Gitもターミナルも使ったことのないデザイナーが、約1.5ヶ月で251コミット・177ファイルを自力で書き、実装前に130件以上の仕様課題を発見・解決しています。デザイナー視点の詳細は 山崎の記事 をご覧ください。 デザイナーがここまで自走できた背景には、エンジニアの伴走がありました。本記事では、当時バックエンドエンジニアとしてデザイナーの伴走を担当した経験から、エンジニアが何をしたのかをお伝えします。この記事を読むと以下のことがわかります。 デザイナーがStorybookを書くために、どんな環境を用意すればよいか エンジニアの伴走で「やること」と「やらないこと」の線引き 導入にかかる工数感 前提 安全に試行錯誤できる環境を作る ツールを整える CUIを使う Node.jsバージョンを揃える Gitを使う Claude Codeを使う デザイナーに伴走する やること・やらないこと 工数 まとめ 前提 本アプローチを適用したプロジェクトについて説明します。 本プロジェクトはB2B向けSaaSアプリに新たな機能を追加するプロジェクトです。 メンバーは、 PdM、エンジニア、デザイナーを含めた5-7名のチームで開発していました。 画面数は31個、ユースケースは23件で、全体工数は約半年と見積もられていました。 なおバックエンドは、AIを使ったユースケース駆動開発にトライしており、その記事は こちら で読めます。 caddi.tech 安全に試行錯誤できる環境を作る コードが書けないデザイナーが触る環境では、何をしても壊れない安心感が最も大事だと考えました。そのため、本番リポジトリとは完全に別のリポジトリ(仕様リポジトリ)を作り、Storybookを配置しました。 技術スタックはStorybook + Vite + React + TypeScriptです。社内デザインシステムをnpmパッケージとして導入し、本番と同じコンポーネントをStorybook上で使える状態にしました。 ディレクトリ構成は、下記の通りで本家リポジトリに移植しやすいように構造に合わせました。 当初はデザイナーが理解しやすいよう、リポジトリ内のディレクトリ構成とStorybookのサイドバー階層を別々に管理していました。しかし、二重管理は認知負荷が高いため、本家リポジトリのやり方を踏襲しました。 storybook/ ├── _template_component.md # コンポーネント用テンプレート ├── _template_page.md # ページコンポーネント用テンプレート ├── pages/ # 本番のディレクトリ構成に対応 │ ├── request/ │ │ ├── component/ # RequestPageコンポーネントで利用するコンポーネントを格納する │ │ ├── RequestPage.mdx # RequestPageの画面仕様を記述する │ │ ├── RequestPage.stories.tsx # Storyを記述する │ │ └── RequestPage.tsx # コンポーネント本体 │ ├── requestDetail/ │ ... ├── common/ ├── locales/ # i18nラベル定義 ├── data/ # ダミーデータ └── types/ # 型定義 コンポーネントは基本的に .mdx / .stories.tsx / .tsxのファイル3点セットで作成する必要があります。このルールはpre-commitフックで自動チェックされます。 また、画面仕様を書くためのテンプレートを設計しました。過去の手戻り事例を振り返ると、実装時に仕様が決まっていなくて困ったことにはパターンがありました。例えば、バリデーションのタイミング、データがないときの表示、デフォルトの並び順などです。これらを項目として洗い出し、テンプレートに落とし込んでいます。内容としては次のようなことが記述されています。 新規or既存の変更 State(Empty, Loading, Partial, Error) カラム定義、ステータス定義 フィルター・ソート仕様 バリデーションルールとエラー表示タイミング スクロール挙動、ページネーション仕様 i18nラベル定義 テンプレートがあることで、デザイナーは「何を決めるべきか」の出発点を持った状態で仕様書を書き始められるようになったり、AIへの入力としても活用できました。 ツールを整える リポジトリを用意しただけでは、デザイナーは自走できません。デザイナーが使うツールについても整えました。 CUIを使う デザイナーにはAIを活用する上で前提となるCUIにまず慣れていただきました。 Mac標準のターミナルでも構いませんが、素の状態では決して使いやすいとは言えません。 好きなターミナルアプリを入れるといいですよと伝えたところ Warpを選んでいました。 設定なしでコマンド履歴や補完がバッチリ効くので、初心者には使いやすいターミナルかもしれません。 山崎さんも最初は「黒い画面で文字を入力するなんてわかりにくいし操作しにくい」と言っていましたが、しばらくすると「GUIが煩わしい、CUI便利ですね」と言い始めました。使いやすい環境を整えた上でしばらく使ってみることが大事だと感じました。 Node.jsバージョンを揃える 山崎さんのNodeバージョンを確認したところ、brew経由でnode@20がインストールされていました。 このインストールの仕方だとプロダクト毎に使うNodeバージョンが異なるバージョンに対応できないのでバージョン管理ツールを使った方が良いと伝え、miseをインストールし、mise経由でNode.jsをインストールしました。 Node.jsは本家リポジトリと同じバージョンとしました。この作業は恐らくエンジニアがやったほうがよいでしょう。 Gitを使う Gitの操作やGitHubの使い方も覚えてもらいました。用語や概念はサル先生のGit入門で学んでもらったものの 、Gitは怖いという印象が拭えなかったため、ペアプロを通じて一緒にコマンドを実行しながら不安を払拭していきました。 仕様リポジトリでは、ブランチはmainブランチのみで、PRは使わずに直Pushを許容する運用にしました。 作業者と作業範囲がぶつかり合うことはほぼないと判断してこの運用にしました。実際ほとんど競合が起こることはありませんでした。 Claude Codeを使う 山崎さんはClaude Codeに関しては既に使ったことがある状態でした。 しかし、コンテキストの扱い方については知らなかったので、同じチームの石田さんが書いた モデルの性能を引き出すための Claude Code コンテキストマネジメント入門 の記事を紹介しました。コンテキストウィンドウの状況をすぐに把握するために、Claude Codeのステータスラインに表示するようにしました。設定方法は「claude code statusline context window」で検索すれば見つかります。 これらの設定をして、コンテキストウィンドウが40%を超えたら/clearするようになったり、コンテキストを汚してしまった場合は/rewindを使えばいいのか！など様々な学びがあったようです。 また、RaycastのWindow Management機能でウィンドウ配置のホットキーを設定し、Claude Codeとエディタの並列配置をワンタッチでできるようにしました。この設定は、文章で読むと大したことないのですが、実際に操作してみると、もうウィンドウ配置をマウスで整えることがなくなります。 デザイナーに伴走する 毎日1〜2時間のデイリーSyncを行いました。Slackのハドルで山崎さんの画面を共有してもらい、操作を見守りつつ注釈ツールで誘導するペアプロ形式で進めました。 初期はGitの操作やStorybookの書き方など、ツールの使い方を教えることが中心でした。慣れてくると、「このステータスの定義はこれで正しいか」「このバリデーションのタイミングはいつか」など、仕様そのものの議論へと移っていきました。 ツールや操作に関する伴走のスタンスは、デザイナーの習熟度に合わせて徐々に変化させました。最初は知識や操作を直接教えるティーチングが中心でしたが、慣れてくるにつれて答えを与えるのではなく気づきを引き出すコーチングへと切り替えていきました。 一方、仕様の議論になったときはコーチングのスタンスをあえて手放しました。エンジニアとデザイナーという役割の壁を取り払い、対等な立場で議論しました。仕様はどちらか一方が教えるものではなく、異なる視点を持ち寄って一緒に決めるものだからです。 山崎さんに感想を聞いたところ、『最初は右も左もわからずもどかしかったですが、のびのび放牧の環境で、教師と生徒ではなく対等な立場で議論できたからこそ、楽しく突っ走れました！』とのことでした。 やること・やらないこと 具体的に、伴走で「やること」と「やらないこと」を次のように線引きしていました。 やること 環境構築やツール設定など、デザイナーだけでは判断・解決が難しい技術的な土台づくり エラーが出たときの原因の切り分けと、解決の方向性を示すこと CLAUDE.mdやテンプレートなど、AIとの協業を助ける仕組みの整備 仕様の議論では対等な立場で一緒に考えること やらないこと たとえ自分が書いた方が早くても、デザイナーの代わりにコードを書くこと AIで解決できる問題にエンジニアが介入すること まずAIに聞いてもらい、それでも解決しない場合にサポートする コードの品質を本番レベルに引き上げること 仕様リポジトリの目的は仕様の定義であり、コード品質ではない 工数 最後に、エンジニア側の工数を正直にお伝えします。導入を検討する方の参考になれば幸いです。 項目 工数 備考 環境構築 トータル5日程度 Storybook + Vite + React + TypeScriptの基盤構築。構築自体は半日で可能だが、フォルダやファイルの調整を繰り返した。最初からポリシーが決まっていればもう少し工数は減らすことは可能。 伴走 毎日1-2時間(同期) × 約2ヶ月 ペアプロ形式の同期作業。デザイナーのオンボーディングを兼ねていた。 コードレビュー 週2時間程度(非同期) 伴走とは別にレビューの時間を確保。このコードレビューを元に伴走の方針を考えた。 まとめ この記事では、デザイナーがStorybookでUIの画面仕様を書くために、エンジニアが何をしたかを紹介しました。AIがあればデザイナーもコードを書ける時代ですが、AIだけでは超えられない壁があります。安全なリポジトリ、仕様書テンプレート、ツール環境といった土台を整え、代わりにやるのではなくCoachingで自走を支える——エンジニアの伴走があることで、デザイナーはAIを最大限活用しながら自分の力で前に進めるようになりました。 エンジニア1名の工数は、環境構築5日 + 毎日1〜2時間の伴走 × 約2ヶ月 + 週2時間のコードレビューでした。決して軽い投資ではありませんが、実装前に130件以上の仕様課題を潰せたことを考えると、十分なリターンがあったと考えています。 同じ課題を抱えるチームの参考になれば幸いです。

こんにちは。CADDi Quoteのプロダクトデザイナー山崎文菜 ( @ayana_yamazaki ) です。 去年までは、Figmaでデザインファイルを完成させて、エンジニアに渡す。それが当たり前だと思っていました。 実装に入ってからエンジニアに「ここのデフォルトの並び順、昇順にしてますけど大丈夫ですか？」と聞かれ、Figmaを見返す。あっ決めてなかった…！ デザインファイルではUIが完成していたのに、実はUXの意思決定が終わっていなかった… この記事は、コードが書けないデザイナーが、エンジニアの伴走を受けながらClaude CodeでStorybookを書き、プロダクトマネージャーとのウォークスルーで130件以上の仕様課題を実装前に発見・解決した実践録です。 Figma→実装のハンドオフで手戻りに苦しむデザイナーやエンジニアに向けて、何をやり、なぜ仕様の抜け漏れを実装前に潰せたのかをお伝えします。 1. Figmaは画面を完成させるが、意思決定を完了させない 2. やったこと: コードで画面仕様を定義し、PdMとUX検証した 3. なぜ効いたか①: コードは曖昧さを許さない 例1: エラー表示の定義から、エラー防止の設計へ 例2: 本番コードを起点にしたUX改善 その他にも、コードで定義する過程で露出した仕様 4. なぜ効いたか②: 触れるものを囲んで多職種で検証できる 例3: PdMとのUX検証で表現を磨き込む 例4: デザインフェーズでテスト観点を先回り 5. 結果 今後の検証 6. 導入に何が必要か 必要だったもの コードが書けないデザイナーが飛び込むと何が起きたか 得られたもの 終わりに: これはデザイナーの仕事なのか？ 1. Figmaは画面を完成させるが、意思決定を完了させない 静的デザインファイル→実装のハンドオフには、2つの問題があります。 1. 静的デザインファイルでは「決めていないこと」が見えない エラーのバリデーションタイミング、Empty State、長い文字列が入った場合の表現…これらを決めなくても画面は完成します。未決定の項目が埋もれたまま先に進む。 2.Figmaはプロダクトの現実と繋がっていない Figma Prototypeは決められた遷移を辿れますし、Figma Makeならインタラクティブなプロトタイプも生成できます。しかしそれらは 本番のコードやデータから切り離された世界 です。既存実装に埋もれた仕様も、実データを流し込んだときの壊れ方も映りません。プロダクトの現実に触れなければ出てこない問いがあります。 2. やったこと: コードで画面仕様を定義し、PdMとUX検証した 最初にClaude CodeでHTMLプロトタイプを作り、画面構成や情報の優先度をPdMと検証しました。大枠の方向が固まった段階で、React + 社内デザインシステムでStorybookに移行。本プロジェクトではFigmaは全く使っていません。 画面仕様書 (.mdx) : カラム定義、ステータス定義、フィルター仕様、スクロール挙動、ページネーション仕様、i18nラベル定義 画面 (.story) : 状態パターン網羅（Default、EmptyState、Loading、全ステータス表示など） UIコンポーネント (.tsx) : インタラクティブに操作できる画面やUIコンポーネント 私はコーディングスキルがなく、すべてClaude Codeで指示を出して書いています。このプロセスを成立させた条件はセクション6で詳しく述べます。 3. なぜ効いたか①: コードは曖昧さを許さない コードで書き、UXを体験し、本番コードを参照する。この3つが重なったことで、ハンドオフまでに定義しきれなかった仕様が、プロセスの力で構造的に炙り出されました。 例1: エラー表示の定義から、エラー防止の設計へ ユーザーを追加するモーダルに、表示名とメールアドレスの2フィールドがあります。FEに「エラー状態」の赤い静止画を1枚描けば補完してもらえますが、UXデザイナーとして品質にこだわりたいところです。コードで書くと、「エラー表示」でもフィールドごとにonChange・onBlur・onSubmitと発火タイミングが分岐します。 これらを定義し、実際にキーボードで操作して挙動を触り比べる過程で、「エラーをどう表示するか」ではなく、「そもそもエラーを起こさない体験」を追求していきました。 onBlurで空白が入力されたらトリム、全角英数字は自動で半角に変換するなど、フロントのみで実装できるエラー防止のUXの詰め。操作しなければ浮かびづらい発想でした。 Storybookでバリデーションの挙動を確認し、仕様書を作成 例2: 本番コードを起点にしたUX改善 新画面にメモ編集機能を設計する際、本番の類似コンポーネントのコードを読み込みました。既存の実装と挙動を把握した上で、長文が入ったときの表示の切り方やアフォーダンスの改善など、元のUIにはなかった設計判断をStorybookで試しながら加えていきました。 コードを起点にしたからこそ、既存UIの設計意図を理解し、それを超える改善の起点が得られました。 その他にも、コードで定義する過程で露出した仕様 露出した仕様 なぜコードで定義すると露出するか グローバル対応の名前の字数（タイ人名の場合30文字を超えることも） ダミーデータを自分で定義するため、「どんなデータでテストすべきか」という問いが発生。PdM調査で名前に関する左記の実態が判明し、あらかじめ崩れ防止や視認性を担保できた Empty State・Loadingなどの状態 状態パターンをStoryとして網羅するため、未定義の状態が残らない 静的なデザインファイルでは、これらを「決めなくても画面は完成する」ため見過ごされることがありますが、コードでは「定義しないと画面が動かない」ため、未決定の項目が残りようがありません。 4. なぜ効いたか②: 触れるものを囲んで多職種で検証できる CADDiは製造業AIプラットフォームであり、製造業では品質を後工程の検査で担保するのではなく、前工程に検査を組み込む 「フロントローディング」 という考え方があります。 例3: PdMとのUX検証で表現を磨き込む Storybook上で実際にアイテムの追加・フィルター・ソートなどの画面操作を試せたからこそ気づけた問題がありました。 業務を再現しながらPdMとレビューを繰り返し、ステータスカラムの表現を改善した例を紹介します。 1回目: ステータス4種、期限切れはテキスト表現 → PdMとStorybook上でフィルターやソートを操作。ITリテラシーが高くないユーザーになりきると、期限切れアイテムを探す時にdateで絞り込む発想が難しいことに気づく 2回目: ステータスに「期限切れ」を追加 → 期限切れかつ未対応/対応中なのかがわからなくなるが、期限切れの時点でユーザーにやれることは少ないため未対応/対応中の区別は不要と判断。 3回目: ステータス5種 → システム的には違和感があるが、デジタルツールに不慣れなユーザーの直感性を優先 ユーザーの実務を再現しながら操作することで、実装前に1-3日サイクルで6回の検証・改善を回せました。 例4: デザインフェーズでテスト観点を先回り 伴走したエンジニアが「この仕様だとテストで何が壊れるか」という後工程の視点で私のアウトプットをレビューしました。例えば「複数タブで別テナントのセッションを開いたとき、メモの書き込み先が混在しないこと」といった観点です。 デザインファイル・画面仕様書がコードと同じリポジトリにあるので、テスト観点がデザインのフェーズで組み込まれました。通常なら実装後のテストで初めて見つかり、仕様修正と再実装の手戻りが発生する問題を、前工程で潰せる構造です。 デザイナーとエンジニア、PdM。この多職種の組み合わせが、UIデザインにおけるフロントローディングとして機能しました。 5. 結果 約1.5ヶ月で以下を達成しました。 PdMとの ウォークスルーを6回 実施 アウトプット: 31画面 、49のStory、39件のMDX (画面仕様書) を作成 131件の仕様の抜け漏れ・UX改善施策 を発見し、すべて実装前に解決 131件の内訳: 種別 件数 なぜ今回の方法で見つかったか 仕様の検討もれ（未定義・矛盾） 60件 定義しないと画面が動かないため、未決定の項目が構造的に露出した UX改善 45件 実際に操作できる画面でPdMと業務を再現し、静止画では気づけない違和感を検出した 実装誤り・既存との不整合 26件 本番コードを参照しながら作業したことで、既存実装との意図しない乖離に気づけた 今までは実装フェーズまで持ち越されていた問題が、修正コストの低い前工程で出てきました。 副次的に、コードベースを理解したことで「この実装ならこのUXが実現できる/できない」をエンジニアと議論できるようになり、デザイナーとしての意思決定の質が変わったと感じています。 今後の検証 フロントエンドへの繋ぎ込み : StorybookはFigmaと同じく中間成果物であり、FEの代替ではありません 担当FEからは「デザイナーの考えた最強のUI持ってこい」と言われており、仕様とUXの意思決定はデザイナーが、実装はFEが引き受けます Storybookのコードがどの程度そのまま流用されるかは現在検証中 再現性 : 別のプロダクト・別のデザイナーへのプロセス展開を開始 6. 導入に何が必要か このプロセスの成立に必要な条件と、飛び込んでみてわかった正直なところを書きます。 必要だったもの 私の試行錯誤を受け止めてもらえる環境がなければ、このプロセスは成立しませんでした。 Claude Codeへのアクセス デザイナーだけでなく、エンジニア1名の伴走 最初から完璧を求めず、Sandbox環境での挑戦を許容するマインドセット 一定のデザインシステム（コンポーネントや状態パターンが構造化されたもの）が整備されていること コードが書けないデザイナーが飛び込むと何が起きたか 恥ずかしながら正直に書きます。 私は入社3ヶ月半、Gitもまともに使ったことがない状態でStorybookでの画面仕様実装を始めました。プロトタイプ制作でOpusのトークンをメチャクチャに溶かし、Sandboxのディレクトリをぐちゃぐちゃにし、リンターエラーが出ているのにAIに聞いて無理やりpushしていました… エンジニアの環境構築のおかげで、2ヶ月で251コミット・177ファイルを書けるようになりました。 詳しくはエンジニアの記事で説明されていますので、ぜひご覧ください！ Storybookでデザイナーが仕様を書く——自走を支えたエンジニアの伴走記録 得られたもの 手戻り工数の削減 : Figma→実装の翻訳コストや差し戻しを削減 実装前の検証の質 : 実務を再現した操作検証でエッジケースや状態定義の漏れを前倒しで潰せる デザインの意思決定の明確化 : 「デザイン側が定義しきれずエンジニアが埋めたUI」をゼロにし、根拠のある実装を届けられる 終わりに: これはデザイナーの仕事なのか？ デザイナーがAIでコードを書き、エンジニアがUXを底上げし、PdMがプロトタイプを作る。職種の境界はどんどん溶けていて、「デザイナーとは何か」がわからなくなりつつあります。 Storybookを書くことがデザイナーの本質的な仕事かと聞かれたら、違うかもしれません。ただ、コードの側に踏み出して初めて見えたことがあります。 エラーをいつ出すか、データがないとき何を表示するか、デフォルトの並び順はどうするか… Figmaでは表現しきれなかったこれらを、今まで誰かが暗黙に決めていました。 境界を越えてみて初めて、自分が決めるべきだったことの輪郭が見えました。 手段がFigmaかStorybookかは本質ではなく、「ユーザーが触れるものに対して、曖昧にしない」ことが自分の責任 だと思っています。 境界を越えると、居心地のいい場所は失います。その先に、もっと強い武器があります。一緒に踏み越えましょう！

こんにちは、Infrastructureチームの前多(@kencharos) です。AIの進化におびえながら、電気の資格の勉強でもしようかと考えている日々です。物理はいいですね。 さて、CloudSQLやAlloyDBで初回構築時に設定されるデフォルトユーザーをそのまま使っている方はいらっしゃいますか?いませんよね? 今回の話はAIネタではなくもっと地味なお話です。 データベースの権限設定のつらみ Terraform Postgres Provider の採用 パスワードの扱いについて CI/CDでの実行 1. Argo CD + k8s での Job実行 2. GitHub Actionsから踏み台サーバーに接続して実行する ownerの変更やowner指定には要注意 まとめ おまけ: 第三の選択肢、Crossplane データベースの権限設定のつらみ スキーマの設定を自動マイグレーションするサードパーティのサービスをそのまま使う場合ならともかく、 自分たちで開発しているサービスであれば、マイグレーションとアプリケーションの実行でDBユーザーの権限は分けた方が安全ですし、 複数サービスでDBを共有する場合なら、データベースやスキーマレベルで権限を分けたくなります。 また、AIツールがSQLを実行することも今後はあり得ると思います。 その場合もAIツールが勢い余ってすごいSQLを発行しても大丈夫なように権限を絞ったDBユーザーを使うようにしておきたいものです。 Google CloudのCloudSQLやAlloyDBではDBユーザーやIAMユーザーの作成はできます。 しかし、RDBMS内の権限付与(Grantなど)は結局RDBMSにログインしてSQLを実行する必要があります。 この手のSQLはどうやって管理しているでしょうか？ prismaなどのアプリケーションのスキーママイグレーションで管理するのも手段の1つです。 ですが最初にマイグレーション用の権限を持つユーザーは作っておく必要があります。 また何らかの理由で開発サイクルとは別のサイクルでDBユーザーを追加、修正することは多々あります。 レプリケーション用のユーザーが欲しいとか、新しいメンバーが参加したからそのIAMユーザーを追加したいとか、要はスキーマ定義とは独立して管理したいわけです。 筆者らは、このような権限付与を手順書にSQLを書いて手動で実行していました。 苦痛を伴う作業と認識しながら、よい代替手段が当時は思いつきませんでした。 これにはいくつか問題があります。 複数環境で繰り返し実行が必要 変更の都度、現状の状態から細かいGrantやRevokeが必要 手順書の修正などで過去の権限付与の内容の修正などが面倒 などの理由から、微妙に権限付与の内容が環境ごとに異なってしまうことがあります。 意図した通りに権限付与ができているのかが把握しづらくなります。 サービスの拡大に伴ってデータベースの数も増えてきたこともありどうにかしなきゃと思い、解決策を探し始めました。 Terraform Postgres Provider の採用 権限管理のツール化を行うにあたり、要件は次の3つです。 手動ではなくCICDなどから実行して作業を自動化できること 宣言的に権限付与を管理できること PostgreSQLの様々な機能(extension, database, schema, grant, default_privileges, replication slotなど)に対応できること 当初はYAMLに権限付与設定を書いて、自作しようかと思っていましたが、 terraform の postgresql provider を見つけたのでこれでいいやとなりました。 ただし、posgresql providerはサードパーティのプラグインですので、扱いには気をつけてください。 要件と概ね一致していましたし、筆者らはTerraformを常用しています。 hclファイルで宣言的に権限設定を管理できるのが大きな理由でした。 (欲を言えば、hclよりも読みやすいフォーマットの方がよかったのですが、それも今ならClaudeなどでサマリできそうだし、まあいいやとなっています) これを使って、以下のような権限設定を作成します。 ownerとなるmigration user、アプリケーション実行用のapplication userを作成する database, schemaは独自のものを作る application userにschema, tableへのgrantとdefault privilegesを設定する。 上記をhclで表現したものが次の通りです。 terraform { required_version = "1.10.5" backend "local" { path = "sample.state" } required_providers { postgresql = { source = "cyrilgdn/postgresql" version = "1.26.0" } } } // プロバイダの設定。ここではデフォルトユーザーやadminユーザーを指定する provider "postgresql" { host = "x.x.x.x" port = 5432 database = "postgres" username = "postgres" password = var.admin_password sslmode = "disable" connect_timeout = 15 } // userの作成 resource "postgresql_role" "migration" { name = "migration" login = true # password_woはstateにパスワードを記録しない。パスワードを変更したい場合は password_wo_versionを変更する password_wo = var.migration_password password_wo_version = "1" bypass_row_level_security = true } resource "postgresql_role" "application" { name = "application" login = true password_wo = var.application_password password_wo_version = "1" } // databaseの作成 resource "postgresql_database" "app_db" { name = "app_db" owner = postgresql_role.migration.name allow_connections = true } // schemaの作成 resource "postgresql_schema" "schema" { name = "app" owner = postgresql_role.migration.name } resource "postgresql_grant" "grant_to_schema" { database = postgresql_database.app_db.name role = postgresql_role.application.name schema = postgresql_schema.schema.name object_type = "schema" privileges = [ "USAGE" ] } # grant role　to table resource "postgresql_grant" "grant_to_application" { database = postgresql_database.app_db.name role = postgresql_role.application.name schema = postgresql_schema.schema.name object_type = "table" # objectsが空の場合は all # objects = [] # privileges は明示する。ここに無いものは revoke 対象になる。 privileges = [ "SELECT" , "INSERT" , "UPDATE" , "DELETE" , "REFERENCES" , "TRIGGER" , "TRUNCATE" ] } # default privileges を指定して、application userに対して新規テーブルの権限を付与する resource "postgresql_default_privileges" "default_privs" { role = postgresql_role.application.name database = postgresql_database.app_db.name schema = postgresql_schema.schema.name owner = postgresql_role.migration.name object_type = "table" privileges = [ "SELECT" , "INSERT" , "UPDATE" , "DELETE" , "REFERENCES" , "TRIGGER" , "TRUNCATE" ] } あとは、初期ユーザーがあるデータベースがあれば、terraform applyで想定通りの権限付与ができます。 宣言的に権限を記述しているので、例えば上記のgrantからprivilegesを足したり削除したりすると、それがapply時にgrantやrevokeとなって実行されるようになります。 基本的にはこれで十分なのですが、細かい点で気をつけたところを次に述べます。 パスワードの扱いについて 前述のサンプルでは、 password_wo を用いてユーザーパスワードを設定しました。 resource "postgresql_role" "application" { name = "application" login = true password_wo = var.application_password password_wo_version = "1" } これは事前にパスワードがわかっている場合に、 実行時引数や環境変数で application_password にパスワードを渡すようにすればstateにパスワードは残らなくなります。 一方でpostgresql provider 1.26.0の時点でこのリソースはephemeral resourceではありません。 ですので次のように、Terraformで動的に生成したパスワードを直接設定するような操作は現時点ではできません。 ephemeral "random_password" "password" { length = var.length special = false upper = true lower = true min_upper = 1 min_numeric = 1 min_lower = 1 } resource "postgresql_role" "application" { name = "application" login = true # これはできない. password_wo = ephemeral.random_password.password.result password_wo_version = "1" } そのため現時点では、筆者らはGoogle Secret Managerに一旦ランダムパスワードを生成・保存して、それを取り出して使うという設計としています。 ランダムパスワードの生成はCloudSQLやAlloyDBのインスタンス作成と同時に行う別のTerraformで行っているので、それと権限設定のTerraformとサイクルを分けています。 CI/CDでの実行 宣言的に権限を記述できるようになったので、バージョン管理もできるしCI/CDとの連携もできるとベストです。 ただし、筆者らの環境ではセキュリティの理由でデータベースサーバーにPublic IPを付与してないので、通常のGitHub ActionsからTerraformを実行してもデータベースに接続できません。 そこで以下の2案を考え、2の踏み台サーバーへ接続する方法を採用しました。 1. Argo CD + k8s での Job実行 GitHubのチェックアウトからterraform実行までをスクリプト化して、k8sのJobとして定義しArgo CDからJobを実行します。 GitHub Appsを準備して、次のようなスクリプトで動きます。 # checkout repo echo " ${ _APPS_PRIVATE_KEY } " > /tmp/gh_cert header = $( echo -n ' {"alg":"RS256","typ":"JWT"} ' | base64 -w 0 ) now = $( date " +%s " ) iat = $((${now} - 60 )) exp = $((${now} + ( 10 * 60 ))) payload = $( echo -n " { \" iat \" : ${iat} , \" exp \" : ${exp} , \" iss \" : ${GITHUB_APPS_ID} } " | base64 -w 0 ) unsigned_token = " ${header} . ${payload} " signed_token = $( echo -n " ${unsigned_token} " | openssl dgst -binary -sha256 -sign /tmp/gh_cert | base64 -w 0 ) jwt = " ${unsigned_token} . ${signed_token} " access_token = $( curl -s -X POST \ -H " Authorization: Bearer ${jwt} " \ -H " Accept: application/vnd.github.v3+json " \ " https://api.github.com/app/installations/ ${GITHUB_APPS_INSTALLATION_ID} /access_tokens " \ | jq -r " .token " ) #checkout git clone https://x-access-token: ${access_token} @github.com/ < org > / < repo > cd < repo > export ADMIN_USER = ${TF_VAR_admin_user} export ADMIN_PASSWORD = ${TF_VAR_admin_password} export DB_HOST = ${TF_VAR_db_host} # run terraform terraform init terraform apply -auto-approve ただ、できればGitHub Actionsで実行したかったので見送りました。 2. GitHub Actionsから踏み台サーバーに接続して実行する 筆者らはデータベースにアクセスする際はVPC内にある踏み台サーバーにアクセスしています。 それと同じことをGitHub Actionsから行います。 前提条件として、次のようなセキュリティ対策を行なっておくと良いです。 Workload Identityを使用する Identity Aware Proxy(IAP) を設定する この方法を採用するにあたって、以下の記事が参考になりました、ありがとうございます。 zenn.dev ポイントとしては、記事にあるようにCloudSDKを別途インストールした上で、beta computeでSSHトンネルを作成することです。 # connect bastion server by beta gcloud beta compute ssh " ${bastion_host} " \ --zone =" ${bastion_zone} " \ --ssh-flag =" -L 127.0.0.1:5432: ${db_host} :5432 " \ --ssh-flag =' -N ' \ --ssh-flag =' -f ' \ --tunnel-through-iap \ --quiet sleep 10 export TF_VAR_admin_user = ${admin_name} export TF_VAR_admin_password = ${admin_password} # 踏み台に接続済みなので、localhostで良い。 export TF_VAR_db_host =localhost terraform init terraform apply --auto-apporve これで、手動でSQLを実行することなく権限設定ができるようになります。 ownerの変更やowner指定には要注意 postgresql providerを使うと、記述の変更が差分反映のSQLとなるので便利ですが、あらゆる変更に対応できない場合があることには注意が必要です。 例えばdatabaseやschemaのownerを変えたりするには、superuserやowner自身である必要があります。 一方で、CloudSQL, AlloyDBのデフォルトユーザーは、 supueruserではなくそれと似て非なるcloudsqladminやalloydbadminというロールが付与されています。 それでsuperuserが必要とされるような変更操作ができないことがあります。 そんな変更が発生する頻度は少ないので、もしそうなった場合は素直にSQLを直接実行して対処する方が良いです。 1つだけ困ったのは、 publicationやreplication slotの作成です。これらのリソースの作成もsuperuserかownerでなくてはいけないので、 Terraformで管理したい場合はproviderに設定するユーザーをdatabaseのownerに切り替える必要があります。 そのためエイリアスを付与したproviderを用意して、特定リソースにそのproviderを指定します。 # 通常のprovider設定 provider "postgresql" { host = var.db_host port = var.db_port database = var.default_database username = var.admin_user password = var.admin_password } # databaseオーナーのprovider設定 provider "postgresql" { alias = "relication" host = var.db_host port = var.db_port database = var.default_database username = var.replication_user password = var.replication_user_password } resource "postgresql_replication_slot" "replication" { # relication slot作成用のproviderを指定する provider = postgresql.replication name = "replication_slot" plugin = "pgoutput" database = "xxxxx" } まとめ GitHub Actionsから踏み台サーバーになかなか接続できなかったり、replication slotの作成でsuperuserじゃない問題に直面した時は頭を抱えましたが、 色々あってできるようになりました。 苦労はありましたが、その効果は絶大で新規サービスの開発で新しいデータベースができた時でも複数環境分のセットアップが迅速、かつ正確にできるようになりました。 興味があれば試してみてもらえたり、他にこんなやり方があるよというコメントもお待ちしています。 おまけ: 第三の選択肢、Crossplane この記事を書くにあたって、改めて色々調べていたら、 Crossplaneのpostgres provider を見つけました。 Crossplaneはk8s上のカスタムリソースとして、インフラなどの様々なリソースを管理するプロダクトです。 なのでこれを使えば、YAMLでデータベースの各種権限を設定できるし、Argo CDを使ってGitOpsでマニフェストを管理できそうです。 Terraformを実行することなく、権限設定が同期できるのでとても便利だなと感じました。 Corssplaneを導入する計画は今のところないのですが、もし導入するならやってみたいと思います。

こんにちは、製造業データ活用クラウド CADDi Drawer でQAを担当しているOshiroです。 業務としては、開発チームと並走し品質保証に関する活動をしています。コードを書くことはほぼ無く、主にテスト設計のドキュメント作成やテスト実施、リリースにおける運用作業に携わっています。 また、自作のカエルのキャラ絵文字を描いて、みんなに使ってもらう「カエルの人」としても活動しています。 このような絵文字を作っています。 今回は、AI活用で非エンジニアでも可能なツール生成術の一例を紹介したいと思います。 PCにツール類のインストール作業は一切不要で、主に Google Workspace のサービスを利用します。 ※Gemini Canvas、Google Sitesの利用を前提としています。管理者の権限設定によっては機能がOFFになっている可能性があります。 やったこと Gemini Canvas でテストデータ生成ツールを構築 Google Sites で社内共有 背景：テストデータって作るのって意外と大変 私がQAとして関わっているプロダクトは、大量の図面データや関連文書を検索してインサイトを得るという特性を持っています。そのため、大量のテストデータが必要となります。 このテストデータを準備するのが意外と大変で、テスト工程が始まる段階でその都度作成したり、保管場所を探しに行ったり、細かな時間を消費していました。 データ作りの対応方法がバラバラだと、人によって対応スピードが変わるので改善をする必要がありました。 解決策の模索：AI活用でどうにかしたい 手軽にテストデータを大量に作るためには、ツールを作れば良いと考えました。 調べると、Geminiの中でCanvasという機能を使えば、画面プレビューをしながらコードが書けると分かりました。 これならUI付きのツールを作れるかもしれないと思い試してみることにしました。 試してみる：Gemini Canvas Gemini画面を開きツール「Canvas」を選択し、とりあえず動作確認してみました。 「図面のサンプルデータの画像が生成できるツールを作りたいです」 という大雑把なプロンプトを書いて送信。 結果、それらしいものが1発で生成されました。 初回で生成された時の状態はこのような形で表示されました。 画像もダウンロードできる。これは使えそうだと確信しました。 ここからは以下のようなプロンプトで、対話形式で機能を追加していきました。 プロンプト指示 実装された機能 「大量データを生成可能にして、出力をPDFファイルにまとめたい」 PDF一括ダウンロード機能 「PDFに保存する画像の数を指定できるようにしたい」 ページ数指定機能 「ランダム性を持たせて次々に新規生成できる形にしたい」 リアルタイム・ランダム生成機能 「新規生成された画像はPDF生成前のストックとして使えるようにしたい」 PDF生成前のストック機能 といった流れで微調整を重ねてブラッシュアップしていき、ツールができあがっていきました。 出来上がったツールの状態がこちらです。 Canvasコードの画面には共有ボタンでソースコードをコピーする機能があり、HTMLのソースコードとしてシェアできるようになっていました。 社内公開してみる：Google Sites 社内では、Google Sitesで共有することにしました。 Google ドライブ で「サイト」を作って、Canvasで生成したソースコードを貼り付けるだけ。 （サイドバー「挿入」 -> 埋め込む -> 埋め込みコード の入力欄） あとはページ設定の調整やURLとなる文字列を決めつつ公開ボタンを押していく簡単な作業でした。 サイトの公開設定としては社内のGoogleログイン状態でないと、アクセスできない状態にしています。 共有して、他のチームにも使えるようにしたところ、各所で喜びの声が聞けました。 「動作確認のために利用するテストデータとして使わせてもらいます」 「こういうのほしかった」 「大量データ生成できて助かってる」 元々は自分のために作ったツールではありますが、みんなの役に立てたので良かったなと感じています。 生成したコード自体は、業務には強く影響しない領域に配置しています。 バグがあったとしてもプロダクトには影響なく、再度Gemini Canvasに読み込ませて追加修正できるので手軽にメンテナンスすることが可能です。 サイトには、新たなページもどんどん追加していけるので効率化できるツールを現在も増やしていっています。 高機能な3Dデータの生成ツールも作れたりします。 こちらが、3Dデータをプレビューしながら穴を開けたり突起物を追加したりできるようなツールです。 この3Dデータ生成ツールは、エンジニアからも「なにこれ！？すごい！Google Sitesでこんなの動かせるの？」と驚かれました。 躓いたポイント・工夫したこと 機能を追加していくうちに、Gemini Canvasでは動くが、Google Sitesにコードを貼り付けた時には動かないことがありました。 その時は、「Google Sitesに貼り付けたら動かなかった。対応して欲しい」という指示で、GeminiがGoogle Sitesでも動作するコードに書き換えてくれます。 また、ランダム性を持たせることには少し悩む部分はありました。Google Sitesに埋め込む際、工夫したのが「ランダムな文言の出し方」です。 毎回AIに考えさせると動作が重くなる懸念があります。そして何より「想定外の変な言葉」が出てくるリスクがあります。 そこで、あらかじめ安全で適切な文言リストをソースコードの中に用意し、そこからランダムに抽出する仕組みにしました。 このリスト作成時には、「著作権や倫理的に問題ないか」をQA目線でチェックしました。 これにより、「爆速で動き、かつ事故が起きない」という安心の社内ツールが完成しました。 終わりに 今回は、ツールのセットアップなしで、非エンジニアでも可能なデータ生成ツール作成の一例を紹介しました。 まずは自分が楽になるためのツールを作り始めたことがきっかけでしたが、自分が困っていたことであれば他の人も同じように困っているかもしれないと思い共有したところ感謝され、自分のチームだけでなく他のチームにも貢献ができました。 また、このツールを使ってもらうことでフィードバックをもらい、新たなアイディアも生まれてきているのでこの活動は続けていこうと考えています。 Gemini Canvasは画面プレビューしながらのコード生成が手軽で強力であると感じています。 一つのアイディアとして参考にしていただければと思います。

こんにちは、昨年キャディ株式会社に入社した佐野です。入社して初めての技術記事になります。 この記事では、これまでの開発経験を振り返りながら、それが推論システムの運用にどう活きたのかを整理してみようと思います。 対象読者 機械学習システムを運用したことがないSRE、バックエンドエンジニアの方々 これから機械学習システムを運用していくSRE、バックエンドエンジニアの方々 伝えたいこと 機械学習のモデル開発経験や機械学習システムの運用経験がなくても、機械学習システム(推論システム)の運用に貢献できます。SREの領域と被るものが大半であるため、今までの経験を活かせることが大半です。 入社前までの経験 直近5年くらいはバックエンド、SREを往復するようなキャリアでした。APIの設計・開発から始まり、DB設計、システム設計などを色々やっておりました。機械学習の経験はというと、プロジェクトで半年ほど画像認識で使用する画像をOpenCVでコネコネしていたことはあります。ただそれも7年以上前なので、記憶の彼方に消えてしまってます。 配属先のチーム キャディに入社後の私の配属先のチームは、Analysis Platformチームで、機械学習システム(推論システム)を開発・運用しています。具体的には、モデル開発以外(システム設計、API設計・開発、インフラ構築など)の業務を全て担っています。 役に立った経験 実際チームでシステムを運用、タスクを消化していく中で感じたことは、バックエンド、SREの経験をそのまま使えるということです。例えば、以下のような経験はそのまま活かすことができます。 システム設計 データリソースの選定 モニタリングやアラートの設計/運用 ネットワーク設計 など システム設計(非同期設計) システム設計については、推論システムだからといって特別なものはほぼなく、通常のシステム設計の考え方(非同期設計など)に似た部分が多いように感じています。その中でも特に非同期設計の経験は役に立ちます。なぜ役に立つかは後述します。 データリソースの選定 この経験も非常に有用だと考えています。推論APIの設計にも依存しますが、モデルによってはAPIのレスポンスが肥大しがちです。例えば物体検出のモデルでは、検出数によってレスポンスが大きくなることもあり得ます。この推論結果をどのデータリソースに格納するのが望ましいかは腕の見せ所であり、面白いポイントだと感じています。Cloud SQLのようなRDB、mongoDBのようなNoSQL、GCSのようなストレージサービスなど様々な選択肢がある中で、要件に応じた選定を行う必要があります。これを決めていくにあたり、これまでのデータリソースの運用経験が非常に活きると考えています。 モニタリングやアラートの設計/運用 推論システムといえど、運用という点ではこれまでのシステムとほぼ変わりません。SLOの定義や、アラート疲れを起こさないための運用設計など、まさにSREの知見が求められるシーンが多かったです。 また私が入ったタイミングで、既存の推論システムをGKEへ移行しており、システムをいかに安全に移行するか、モニタリングをどう再設計するかなどの知見も非常に有用でした。 zenn.dev 通常システムとの違い 今までの経験がいきるとはいえ、推論システムと通常システムには多少違いがあります。自分の中で感じた部分を少し書ければと思います。 非機能要件: 非同期処理にしたい モデルによって推論に時間がかかることはしばしばあります。例えば物体検出のモデルでは、検出数が多ければ多いほど推論に時間がかかるため、処理時間が数十秒になることも珍しくありません。そのため非機能要件を定めるに当たっては注意が必要になります。システムを運用する視点では、非同期処理によせることができれば、同期処理と比較し、シビアに処理時間を気にしなくて良くなります。 また、当たり前ですがGPUは通常のインスタンスと比較してコストが高くなります。そのためGPUを使用しないときは、インスタンスを停止してコストを抑える必要があります。具体的にはkubernetesの場合はKEDAのScaledObjectなどを使い、使用していない期間のインスタンスの停止などの工夫を行い、コストを抑える必要があります。 このようなこともあり、非同期処理の経験が非常に活かせると考えています。 技術選定: GPUを利用するための術を知りたい 推論システムを運用していく上で避けて通れないのは、GPUの運用です。私の知る限りGoogle Cloudでは、Compute EngineはもちろんのことマネージドサービスであるVertex AI、サーバーレスであるCloud RunでもGPUを扱えます。これらの選択肢の中で、何が要件としてマッチしているかは検討できるようになる必要があると感じています。 docs.cloud.google.com 余談ですが、Compute Engineのマシンタイプでは、A2 マシンシリーズやN1 マシンシリーズ(T4)、G2マシンシリーズ(L4)という名前が出てきます。最初これらのアルファベットを聞いて、何を言ってるのかさっぱりわからなかった記憶があります。 docs.cloud.google.com リソース管理: GPUを効率的に使いたい GKE上でGPUを効率的に使用するにはいくつか方法があります。マルチインスタンスやタイムシェアリングなどの方法があります。私はまだ実装経験はありませんが、これらをどのように使っていくかはまさに推論システムの特徴なのではと感じています。 docs.cloud.google.com ライブラリ管理: マイナーバージョンの更新であっても細心の注意を払いたい 機械学習で使用されるライブラリであるnumpyやtorchなどのバージョン更新には細心の注意が必要です。たとえマイナーバージョンの更新であってもnumpyは2.0系統であれば、推論結果に影響が出る可能性があるようです。私もPR作成時に意図せずバージョンが上がった時があり、機械学習エンジニアに指摘してもらうことがありました。 最後に まだまだ入門したばかりで、学ぶことも多々あると思いますが、SREやバックエンドでの経験は確実に活き、運用できていると感じます。皆さんもぜひチャレンジしてみてくださいね！

こんにちは。キャディ株式会社の Analysis Platform Group で MLOpsエンジニアを務めているAmaniです。 普段はキャディの各サービスの裏側で稼働する機械学習基盤やバックエンドの開発、およびアプリケーションとの連携部分を担当しています。 前半期は、社内の機械学習ワークロードを既存のマネージドサービスから Google Kubernetes Engine (GKE) に移行するプロジェクトを進めていました。 その過程で、shadow deploy / mirroringの重要性を改めて強く認識する出来事がありましたので、本記事では、その背景と学びについて書きます。 背景：機械学習ワークロードのGKE移行 Shadow deploy導入までの経緯 とはいえ、本番データでは簡単にテストできない 解決策としての shadow deploy / mirroring コストとの向き合い方 まとめ 背景：機械学習ワークロードのGKE移行 前半期は、社内の機械学習ワークロードを Google Kubernetes Engine (GKE) に集約するプロジェクトを進めていました。 従来の構成では、ワークロードは大きく同期推論と非同期推論の2種類に分かれており、Google Cloud の Vertex AI、Compute Engine、Cloud Run を組み合わせて構築されていました。 これらを運用・開発の両面で扱いやすくするため、ワークロードをGKEへ統合しています。 移行の背景や全体的なメリットについては、同じAnalysis Platform GroupのHirokaが以下の記事で詳しくまとめているので、興味がある方はそちらもぜひ参照してください。 zenn.dev 移行対象となるモデルは合計で15個あり、それぞれが異なる特性（パフォーマンス要件やリソース消費）を持っています。 例えば、CADDi にアップロードされる図面に含まれる製造業特有の記号を検知するモデルや、それらを分類するモデル、文字を抽出するモデルなど、多様な役割のモデルが含まれています。 さらに、これらのモデルを呼び出す経路も一様ではなく、APIや大規模な前処理パイプラインなど、合計で5種類以上のクライアントが存在していました。 クライアントの多くは別チームによって開発・運用されているため、移行にあたっては各チームとの調整も重要なポイントでした。 これだけのモデル数・クライアント数を対象に、Claude CodeやDevinといったツールも活用しながら、グローバルなメンバーで短期間に移行を完了させた点については、それ自体で一つの記事になる規模の取り組みですが、本記事ではその中でも、shadow deployによって得られたMLシステムの信頼性に焦点を当てます。 Shadow deploy導入までの経緯 MLモデル移行作業は、まず同期推論モデルから開始しました。影響範囲が比較的小さいモデルを選定し、パイロットとして移行を進めました。 信頼性を担保するため、不具合が発生する前提でロールバックしやすい設計とし、あらかじめロールバックプランも用意しました。 移行後の構成に対しては、関係チームと連携しながら負荷試験・動作確認・精度検証を実施し、必要なチューニングを行ったうえで、クライアントの接続先を新しいシステムへ切り替えました。 切り替え直後は大きな問題もなく、安定して稼働しているように見えましたが、切り替えから2日後、一部のリクエストで以下のようなエラーがバースト的に発生しました。 {"error":{"code":400,"message":"Invalid request: Input should be a valid dictionary or object to extract fields from","status":"INVALID_ARGUMENT"}} 影響範囲は限定的でしたが、原因を即座に特定できなかったため、SLO内ではあったものの、リスク回避を優先して移行前の推論システムへロールバックを実施しました。 後続の調査により、原因は上流システムから送られてくる一部リクエストに含まれる例外的なヘッダーであることが判明しました。 移行前のVertex AI ベースのシステムではこのヘッダーを許容していた一方で、移行後のシステムではエラーとして扱われていました。 さらに、このヘッダーは本番環境のごく一部のリクエストにのみ含まれており、サンプリングされたテストデータでは再現されないパターンでした。 このようなケースは、オフラインテストだけで事前にカバーすることが難しい典型例といえます。 結果として、ロールバックしやすい設計と事前に準備していたプランにより、障害に発展する前に旧システムへ切り戻すことができて、その後、該当のケースに対応する形で新システムの修正を行いました。 今回の事例はヒヤリハットにとどまりましたが、ここで改めて感じたのは、 複数チームが関与する複雑なシステムほど、本番データに基づく検証が不可欠になる という点です。 とはいえ、本番データでは簡単にテストできない 一方で、本番データには顧客データが含まれますので、セキュリティやガバナンスの観点から、自由にテストに使えるものではありません。 この「必要だけど使えない」というギャップは、特にMLシステムにおける推論結果の品質や安定性の検証において大きな課題となります。 たとえば、 データ分布の偏り 想定外の入力パターン 上流システムの揺らぎ といった要素は、オフラインのテストデータではどうしても再現しきれません。 セキュリティやガバナンスの制約もあり、実質的には本番相当の環境で検証を進める必要がありました。ここでいう「本番でテスト」は直接本番システムに影響を与えるものではなく、本番と同じ入力を用いて裏側で挙動を観測する、いわゆるshadow deployを指しています。 解決策としての shadow deploy / mirroring 上記のヒヤリハットを踏まえ、移行プロジェクトの残りの対象モデルでは、簡易的なshadow deploy / mirroringを導入することにしました。 Shadow deployとは、短く言うと「新しいバージョンを旧バージョンと並行で動かし、本番と同じ入力を受けさせながら、その出力はシステムやユーザーには影響を与えない形で比較対象として扱うデプロイ手法の一つ」です。 今回の移行プロジェクトでは、移行後のモデルを「セキュリティが担保されている本番環境で本番と同じ入力」で裏側で動かし続け、既存モデルと並行して挙動を観察しました。もちろん、CIテストやstaging環境での負荷試験・精度試験など、デプロイ前の一通りの検証を終えたうえで、最終確認として実施しています。 移行対象の既存システム図（イメージ）は以下の通りです。 図1 既存システム図 スケジュール制約を踏まえ、まずは「検知と差分把握」にフォーカスした最小構成で進め、以下の図のようなシステムを構築しました。なお、図が複雑にならないように、クライアントおよびモデルはそれぞれ1つに簡略化して示しています。 図2 Shadow稼働期間中のシステム図 推論結果の比較検証に加えて、裏側で両システムのログやパフォーマンスを継続的に監視していました。その結果、いくつかの例外的なケースもユーザー影響を出さずに本番環境で発見することができ、調整後に本番切り替えを行うことができました。本番切り替え後のシステム図は以下の通りです。 図3 切り替え後のシステム 比較検証期間中に検知・修正できた例外的なケースとしては、以下のようなものがありました。 新旧システム間のパフォーマンス・リソース差分 従来は Vertex AI や Compute Engine 上で実装されていた推論基盤を、GKE上のLitServeへ移行したことで、実行基盤およびフレームワークの両面に変更が入りました。そのため、既存システムと同等以上のパフォーマンスが得られるかを改めて検証する必要がありました。 その検証にあたっては、テストデータでは本番トラフィックの分布や特性（検出対象の数など）を正確に再現することが難しいという課題がありましたが、shadow deploy を用いることで、本番データを活用した確実な検証が可能になりました。 またこの過程では、timeout設計の重要性も再認識しました。特にバッチ処理や長時間実行されるリクエストでは、旧システムとの前提の違いによりタイムアウトの発生条件が変わり、設定値の見直しが必要になりました。あわせて、timeoutを長く設定しすぎるとリソース占有時間が増え、結果としてコストが増加するため、性能だけでなくコストとのバランスを踏まえた設計が重要になります。 実データでのみ発生するエラー 検知対象が例外的に多い図面において、システムリソースが圧迫されるケースがありました。元システムでは問題なく処理できていたものの、移行後のシステムではエラーが発生しました。 この問題は、LitServe、Kubernetes、Google Cloud Pub/Sub のパラメータチューニング（同時メッセージ数、batch size など）によって解決しました。 精度のギャップ 一部のモデルでは、新システム側で前処理が正しく適用されていないケースがあり、旧システムとの差分として推論結果の精度ギャップが発生しました。 これは shadow deploy によって初めて検知できた問題であり、前処理の実装漏れに起因するものでした。 上記の経験を踏まえ、特に複雑なMLシステムにおいては、shadow deployの仕組みを使って継続的にデータの性質や分布を把握することが、より信頼性の高いシステムにつながると強く実感しました。 この考え方自体はセオリーとして理解していたものの、今回の経験を通じてその重要性を改めて認識しました。 こうしたメリットを得られることが前提となる一方で、次に論点となるのはコスト面です。特にMLのワークロードではGPUリソースの利用も伴うため、無視できない要素になります。 この点についてはトレードオフもあるため、次の章で整理します。 コストとの向き合い方 Shadow deployは、トラフィックの複製と追加の推論実行が発生するため、インフラコスト（特にGPUによる推論コスト）の面でオーバーヘッドが生じます。 ただし、用途に応じて設計することで、無駄なコストは抑えられます。 例えば： 機能確認が目的の場合 フルスケールである必要はなく、縮小構成で数日間動かすことで、挙動や例外ケースの検知には十分なケースが多いです。 負荷耐性の確認が目的の場合 フルスケールで短時間（数時間〜1日）実施する方が効率的です。 さらに、すべてのリクエストを対象とするのではなく、トラフィックの一部のみをshadow側に流すといった制御を行うことで、コストと検証精度のバランスを取ることも可能です。 このように目的と検証対象を明確にすることで、「必要十分なshadow環境」を設計できます。 まとめ 今回の移行を通して、特にMLシステムにおいては「本番環境でしか見えない挙動」が一定割合で存在するという前提に立つ必要があると感じました。 オフラインテストやstaging環境での検証だけでは、データ分布や上流システムの揺らぎまではカバーしきれません。 そのギャップを埋める手段として、shadow deployは有効です。特に複雑なMLシステムにおいては実質的に必須の仕組みだと考えています。 一方で、コストや運用負荷とのトレードオフがあるため、目的を明確にした設計が重要になります。 さらに技術面以外の学びとして、プロジェクト管理の観点では、MLモデル（そしてAPI全般）の移行は単純にモデル数に比例するものではなく、各モデルに紐づく呼び出し元クライアントとの関係性に依存して工数が増えるという点があります。特に1つのモデルに複数のクライアントが存在する場合、その調整や影響確認の分だけ工数は増加します。 今回の移行プロジェクトでは最小構成でshadow deployを導入しましたが、今後は Istio のトラフィックミラーリングなど、より標準化された仕組みの活用も検討しています。

※本記事は、こちらの記事を和訳したものです stratomere.com 序章 航空機が音速を超えると、衝撃波が発生する。衝撃波は周囲の空気が伝わる速度よりも速く移動するため、周囲の空気がその擾乱を吸収しきれず、不連続性が生じる。これがソニックブームである。 池の水面に広がる波紋のように、衝撃波は外側へと伝播し、その影響は距離とともに薄れていく。AIサービスの需要は、技術サプライチェーンが吸収できる速度をはるかに超えて拡大している。マイクロソフトのCEOによれば、当初は大規模な言語モデルの学習と実行にGPUが必要だったが、今ではそれらを動かすためのエネルギーが課題となっている。こうした波紋は私たちの日常生活にも波及し、データセンターの需要が電力網の容量を圧迫するにつれて電気料金が高騰し、限られた半導体供給を巡って家電製品同士の競争が激化するにつれて、家電製品の価格も上昇している。 物理的なサプライチェーンは、ソフトウェアのようなスピードで変化に対応できない。半導体工場や発電所の建設には、数十億ドルもの設備投資と数年にわたる期間、そして建設と運営に必要な人材が不可欠である。需要が明確で資金も潤沢にある場合でも、生産能力を一夜にして拡大することはできない。この媒体は、急激な変化に抵抗する。 物理的および経済的な制約によって計算能力が制限される世界において、ソフトウェアアーキテクチャはますます企業戦略の表現としての役割を担うようになっている。それは、顧客の需要と希少で高価なリソースとのバランスを取り、それによって何が拡張可能で、何が停滞し、何が非経済的になるかを決定する。 豊富な資源に基づいて構築されたソフトウェア 数十年にわたり、ソフトウェアはハードウェア性能の着実な向上という環境の中で発展してきた。ムーアの法則のおかげでトランジスタ数は約2年ごとに倍増し、より高速なプロセッサ、より高速なネットワーク、そしてより多くのメモリが実現した。デナードのスケーリングは、トランジスタ密度の向上と駆動電圧の低下によって電力密度を抑制することで、この進歩を持続させることを可能にした。しかし、メーカーがマルチGHz帯に進出し、コア電圧がトランジスタの閾値電圧に近づくにつれて、この傾向は鈍化した。小型化に伴う非効率性が増幅されたことも相まって、電力密度は持続不可能な熱特性に近づいた。 IntelのXeon 6やAMDのEPYC 9005シリーズといった最新のハイエンドデータセンターCPUは、前世代と同じクロック周波数範囲で動作し、性能向上の大部分はシングルコア性能の向上ではなくコア数の増加によるものであり、ソケットあたり200コア近くに達することもある。しかし、キッチンで料理人を増やしても必ずしも夕食の準備が速くなるわけではないように、コア数を増やしてもコンピュータの速度が自動的に向上するわけではない。マルチコアCPUは高度な協調メカニズムを必要とし、これらの新たな協調の課題をソフトウェアに押し上げ、ロック、セマフォ、そして並列コンピューティングに特化した研究分野を生み出した。これらの概念は、ソフトウェアチームに大きな認知負荷をかけ、顧客に機能を提供する方法だけでなく、基盤となるハードウェアの利用率を最大化して高性能なユーザーエクスペリエンスを提供する方法についても考えなければならない。 ハードウェアによってもたらされるこうした複雑さに対処するために、私たちは詳細を隠すための抽象化を作り出す。モバイルアプリ開発者はAPIのことだけを考えればよく、3GPPやLTEといったAPIを支えるセルラー技術を理解する必要がない。ウェブサイトを構築する人は、豊富なアニメーションやグラフィックに集中でき、それらを支えるグラフィックレンダリングパイプラインについて心配する必要はない。ジョン・オースターハウトは著書『ソフトウェア設計の哲学』の中で、この原則を的確に捉えている。つまり、複雑さをカプセル化するシンプルなインターフェースを備えた「深い」モジュールを構築することで認知負荷を軽減し、組織の拡張性を高めることができる。 パブリッククラウドの登場はこの抽象化をさらに推し進めた。物理的なコンピューティングリソースはAPIの背後に移り、サーバーの調達やデータセンターの稼働開始を待つ必要がなくなった。新しいコンピューティングクラスターはクリック一つで利用できる。すべてのハードウェアを調達するために必要な設備投資さえも、従量制の運用費用として抽象化された。クラウドプロバイダーは規模の経済性を活用することで、一見すると豊富なコンピューティングリソースを提供し、摩擦をほとんど感じることなく、数千台のサーバーに垂直方向および水平方向に拡張できる選択肢を与えた。今や、特定のソフトウェアパフォーマンスの課題を、単により多くのコンピューティングリソースとメモリを投じることで、つまり資金調達によって解決するオプションが生まれたのだ。しかし、現代のワークロードの要求の急激な変化により、これらの回避策の一部が限界に達し始めている。 メモリの逼迫 抽象化は問題を分解し、人間が扱いやすくするのに役立つが、根本的なパフォーマンス上の課題を解決するものではない。並列化されたワークロードが増加するにつれて、特にGPUやその他のアクセラレータにおいて顕著に見られるように、課題は並列計算を実行することから、十分なデータを効率的に供給することへと変化した。 1990年代後半にNvidiaによって普及したGPUは、もともと並列化が容易で反復的なグラフィックス処理パイプラインを高速化するために開発された。これらの特殊な技術は並列処理の限界を押し広げてきた。実際、最新のデータセンターGPUは数万個のコアを搭載し、同時に動作して毎秒数千兆回の計算を実行する。追いきれないほどのゼロの数である。同様に、数万人の料理人がいるキッチンでは、全員を忙しくさせるために大量の食材が絶えず流れなければならない。演算コアにデータを流し込むこの能力、しばしばメモリ帯域幅と呼ばれるもの、は容易にボトルネックになり得る。 メモリ技術は長年にわたって進歩してきたが、トランジスタと電力密度の課題によりシングルコアCPUのパフォーマンス向上が大幅に鈍化したのと同様に、メモリ密度の向上も鈍化している。より多くのメモリチップを並列に配置することで帯域幅を拡張できるが、PCB上の物理的なスペースは有限であり、密度と帯域幅は相互に関連する制約となる。高度に並列化されたワークロードは、対応する大量のメモリと、データをやり取りするための帯域幅を必要とする。ほとんどのコンピュータは、半世紀前に誕生して以来、何度か改訂されてきたDRAMと呼ばれるメモリ技術を使用している。最新の改訂版であるDDR5は、チャネルあたり50GB/秒以上を実現しており、DDR4の約2倍の速度である。これらは大きな進歩だが、GPUの性能が向上するにつれて、大規模言語モデルのワークロードはメモリにさらに多くのものを要求するようになった。計算能力が利用可能なメモリ技術を追い越すこの現象は、しばしば「メモリの壁」と呼ばれる。 このメモリの壁を打破するのに役立つ技術の一つが、HBM（高帯域幅メモリ）だ。2010年代半ばに初めて登場したHBMは、メモリチップを垂直に積み重ねることで、より高いビット密度と帯域幅を実現する。各階に専用エレベーターを備えた高層マンションを想像してみよう。これにより、より多くの人が同時に建物に出入りできる。シリコンを積み重ね、これらの「エレベーター」を織り込む複雑な工程のため、HBMは標準的なDRAMと比較して製造工程における歩留まりと効率に課題を抱えている。この課題に加え、ハイパースケーラーからの需要も、今日見られるメモリ不足の一因となっている。GPUサプライチェーンで始まった衝撃波は、メモリにまで及んでいる。 CPUは中心的な役割を担わなくなる 今日のメモリ制約が顕在化するずっと前から、ハードウェアとソフトウェアのアーキテクチャは、スループットの向上と専門化の進展に対応するために再編成されてきた。過去10年間、シングルコアCPUの性能はほぼ停滞している一方で、ネットワーク帯域幅は桁違いに増加した。現代のオフィスネットワークは一般的にギガビットイーサネットで配線されており、ほとんどのデータセンターは現在100GbEをはるかに超える速度で稼働している。わずか2年前の2024年には、800GbEが標準化された。これは、4K映画1本を1秒未満で転送できる十分な帯域幅であり、単一のCPUコアが処理できる速度をはるかに上回る。 GPU間通信の需要の高まりが、高帯域幅化の傾向を加速させている。今日の大規模言語モデルは非常に大きいため、単一のGPUでは実行できない。GPUのクラスタ全体が必要となる。データ量が単一のCPUで効率的に処理できる量を超えて増加するにつれ、最新のシステムはCPUをデータパスから切り離すことで対応してきた。高速トラフィックをCPU経由でルーティングするのではなく、専用のシリコンがデータ転送を直接処理し、CPUはオーケストレーションの役割を担い、操作の設定、ポリシーの適用、例外処理を行う。NVLinkなどの専用インターリンクはこの変化を象徴するものであり、CPUを経由せずにGPU同士を直接接続することで、低ジッター、低遅延、高帯域幅を実現する。 このパターンはGPUに限ったものではない。イーサネットNIC（ネットワークインターフェースカード）は、高度なコンピューティングデバイスへと進化し、VXLANなどの最新のカプセル化プロトコルからRDMA（リモートダイレクトメモリアクセス）などの技術まで、あらゆる処理をCPUからオフロードできるようになった。従来、NICはネットワークパケットをオペレーティングシステムのネットワークスタックに渡し、ネットワークスタックがペイロードを抽出してユーザー空間プロセスに転送して処理を行っていた。しかし今日では、ネットワークトラフィックが高速すぎて、CPUによる効率的な処理が困難になっている。現代のデータセンターの基準からすると比較的平凡な100Gbpsでも、単一のCPUコアでネットワークを飽和させることはほぼ不可能である。ネットワークが高速すぎるため、CPUは利用可能な帯域幅を十分に活用できるほど十分なバイト数を迅速に送信することができない。このCPUボトルネックを回避するため、NICはCPUの関与なしに、RAMから直接データを読み込み、処理し、ネットワーク経由で送信する。 同様に、ストレージの世界では、NVMe SSDはCPUを介してデータを処理する代わりに、PCIeバス上でDMA（ダイレクトメモリアクセス）を利用してシステムメモリとの間でデータを転送する。これは、レストランの荷降ろし場からパントリーまで専用の独立した経路を作り、厨房の料理人が食材を運ぶ手間を省くことと同じようなものだ。ストレージとネットワークの両方におけるこれらの進歩により、NVMe-oF（NVMe-over-Fabrics）などの技術を利用して、ネットワーク経由でリモートのNVMeドライブにほぼローカル接続と同等の速度でアクセスできるようになった。これらの技術は、最新の高度なNICを活用して高帯域幅のデータ転送をCPUからオフロードする。 ワークロードパターンの変化に伴うこうした技術的変化は、ハードウェアだけにとどまらない。大規模な需要ショックはシステムが動作する環境そのものを再構築し、ソフトウェアアーキテクチャはシステムが動作するハードウェアと一緒になって処理を行う。 物理とソフトウェアが出会う場所 データベースは、コンピューティング、メモリ、ストレージ、ネットワークの交点に位置し、これらのダイナミクスを非常に明確に把握できる。データベースは性能の技術的な限界で動作し、レイテンシとスループット、一貫性と可用性など、様々なトレードオフを強いられる。 Cassandraなどの有名なデータベースで採用されているシェアードナッシング（Shared Nothing）アーキテクチャは、リソースの完全な分離を重視し、各ノードが独自のCPU、メモリ、ストレージを備えている。他のノードへの依存関係はないが、ワークロードが一定でない場合、ハードウェアリソースがアイドル状態になる可能性があることを意味する。CPU、メモリ、ストレージの比率は動的に変更できないため、ハードウェア利用率を最大化するには、比較的安定したワークロードパターンが必要となる。イベントログ用のデータベースは、大容量のストレージを必要とするが、読み取りクエリは非常に少ないため、計算要件は低くなる。eコマースストアで使用される製品データベースは、買い物客からの読み取りクエリが多数発生する可能性があるが、ストレージ容量は比較的少なく、販売される製品数に応じてのみ拡張される。言い換えれば、シェアードナッシングアーキテクチャでは、リソース比率のミスマッチがアイドル状態のシリコンへの支払いやパフォーマンスのボトルネックに直結する可能性がある。 対照的に、シェアードストレージアーキテクチャは、データストレージ層をCPUやメモリなどのコンピューティングリソースから分離する。この概念は、GoogleがBigQueryで初期に取り組んだことに端を発している。これにより、CPUとメモリのリソースをストレージ要件とは独立して拡張できるため、特にクラウド環境において、より高いリソース利用率を実現できる。2025年にDatabricksに買収されたデータベース企業Neonは、コンピューティングとストレージの分離を可能にするために、Postgresストレージ層の大部分を再設計した。これにより、データ量とは独立して負荷に応じてリソースをスケールアップおよびスケールダウンできるようになり、常時専用リソースを必要としない一種の「サーバーレス」データベースが実現した。 ElasticsearchやClickHouseのようなシステムもこれと似たシェアードストレージアーキテクチャを採用しており、Amazon S3などのサービスからの安価で耐久性の高いオブジェクトストレージの可用性によって実現されることが多い。これらのストレージサービスは、読み取り後書き込み整合性や条件付き書き込みのようなプリミティブを提供することで、同時読み取りと書き込みを処理できる分散した一貫性のあるストレージを提供するという難問を解決に貢献する。Apache IcebergやDelta LakeといったオープンなLakehouseフォーマットは、この変化を象徴するものであり、コモディティ化された共有ストレージの上に、より高レベルのデータセマンティクスが重ねられている。 ベクトル埋め込みを利用したAI関連サービスの需要が急増したことで、ベクトル検索を中心とした新しいデータベース開発が急増し、この分離が主流になりつつある。現在の最先端のベクトル検索アルゴリズムには、複雑なチューニングなしで動的な挿入とリコール性能のバランスが取れていることから多くのデータベースで採用されているHNSW（階層型ナビゲーション可能なスモールワールド）のバリエーションが含まれている。しかし、これらのグラフベースのアルゴリズムは、メモリ内のデータ構造を走査する必要があるため、メモリをかなり消費し、データベースの計算コストを増大させる。ストレージ容量とは独立して計算リソースを動的にスケールアップおよびスケールダウンできるアーキテクチャを採用することで、データベースは限られたハードウェアリソースの利用率を高めることができる。 ワークロードパターンが変化し、ハードウェアが進化するにつれて、データベースアーキテクチャは、そのアーキテクチャに内在するトレードオフを浮き彫りにせざるを得なくなった。今日の状況では、コンピューティング、メモリ、ストレージ、ネットワークという4つの柱をどれだけ密接に結合するかという決定は、パフォーマンス特性だけでなく、ハードウェアの利用率、コスト、スケーラビリティにも影響する。データベースはシステムの物理的な限界に近い位置にあるが、その根底にあるダイナミクスはデータベース特有のものではない。ソフトウェアが強い制約の下で動作する場合、アーキテクチャの選択は技術的な成果だけでなく、経済的な実現可能性にも影響を与え始める。ここに明確な答えはない。どのアーキテクチャも、どの制約が最も強く影響するかという賭けを内包している。それを誤ると、もはや存在しない世界に合わせて最適化したことになる。 圧力下における抽象化 抽象化は無料ではない。それらが生み出された環境の前提条件に従って価格付けられている。数十年にわたり、ハードウェアの普及が進んだことで、そのコストは容易に無視されてきた。しかし、物理的な制約が強まるにつれて、抽象化に内在する隠れたコストが再び明らかになりつつある。 抽象化の中には、実質的にコストがかからないものもある。例えば、スマートポインタやジェネリクスなどが挙げられる。これらのメカニズムは、実行時のパフォーマンスを損なうことなく、開発者の認知負荷を軽減する。一方、コストがかかるものもある。ガベージコレクションは、実行時に一時停止が発生する代わりに、開発者が変数のライフタイムを管理する必要をなくす。仮想関数は、パフォーマンスの低下と引き換えに、実行時の動的なディスパッチを可能にする。組み込みシステムや高性能コンピューティングでは、C、C++、Rustといった言語が広く使われている。これらの言語は、開発の複雑さや認知負荷を犠牲にして、実行時の動作を制御可能にする。これは、すべてのバイトとすべてのサイクルに目に見えるコストがかかる状況では、合理的な選択と言える。 現代において最も重要なソフトウェアの一つであるLinuxカーネルは、ユーザー空間のプログラムがハードウェアの詳細を気にしなくて済むようにしてきた。そのシステムコールはハードドライブやNICに関する詳細を抽象化し、メモリ、ファイル、ネットワークのようなプリミティブを扱うための安定したインターフェースを公開する。カーネルはドライバーを通じてハードウェアを直接管理・通信し、最終的にそれらを抽象化された汎用リソースとしてユーザー空間に提供する。これらは抽象化だけでなく、関心の分離も提供する——カーネルはハードウェアリソースが適切に管理・保護されることを保証し、ユーザー空間はユースケースにより集中する。 ハードウェアの限界で動作する場合、これらの抽象化のパフォーマンスオーバーヘッドは、利点を上回り始める可能性がある。ネットワーキングとストレージ技術がCPU性能に対して大幅に進歩するにつれ、増大する需要に追いつくソフトウェアの能力が重要になる。メモリのコピーやコンテキストスイッチは、毎秒数百万回繰り返されると、その負荷が蓄積される。LLMベースのサービスに対する現在の需要は、こうしたプレッシャーを大幅に加速させている。その衝撃波は、ハードウェアの不均一な進歩によって既に負荷がかかっていた抽象化全体に波及し、もはや無視できないコストを露呈させている。 例えば、数十ギガバイトものリアルタイム高解像度ビデオをネットワーク経由でSSD搭載のリモートストレージデバイスに送信するアプリケーションを考えてみよう。データは、ビデオ送信アプリケーションのユーザー空間メモリからカーネル、NIC、光ファイバーケーブルを経由して受信側のNIC、受信側のカーネル、ユーザー空間、そして再びカーネルへとコピーされ、最後にSSDに書き込まれる。各ステップでデータは再配置され、時には仮想的なデジタルエンベロープにカプセル化され、受信側で取り出される。コンピュータからより多くのパフォーマンスを求めるにつれ、この仮想的な書類のやり取りのオーバーヘッドが明らかになる。 このシャッフルは、カーネルとユーザー空間の抽象化レイヤーの結果だ。データはカーネルを介して出入りする。2010年代後半、データセンターのネットワークは100Gbpsを超え、この抽象化を回避する「近道」を見つけたいという要望が高まった。DPDK（Data Plane Development Kit）は、カーネルの抽象化を完全にバイパスし、カーネルを介さずにユーザー空間アプリケーションがNICと直接通信できるようにする業界標準フレームワークである。ネットワークスタックの責任をアプリケーションに移し、カーネルのセキュリティ保証と多重化機能の一部を犠牲にする代わりに、処理速度を向上させる。メモリコピーとコンテキストスイッチを削減することで、DPDKは、高帯域幅でパフォーマンスを重視するアプリケーションが、カーネルを経由する場合と比較して2～3倍の効率を実現できるようにしている。DPDKにはトレードオフがあり、万能の解決策ではないが、機会費用の方程式が変化するにつれ、業界がこれらの抽象化の境界を再構築するために動いてきた多くの方法の一つだ。 環境の変化、技術の進歩、ワークロードの変化に伴い、抽象化の概念を再検討する必要が生じている。コスト、パフォーマンス、経済性に関する暗黙の前提は、プレッシャーがかかった時に明確になる。これらのマクロな動きに気づかないか、適応を拒むことは、隠れた負債の一形態を積み重ねる——システムとプロダクトは健全に見えるが、負荷がかかると破綻してしまうのである。 ハードウェアへの意識 2025年以降にリリースされたデータセンター向けGPUには、数年前には存在しなかった4ビットおよび8ビット浮動小数点表現であるFP4とFP8での動作に特化したモジュールがシリコンに組み込まれている。これらの超低解像度数値表現は、LLMのメモリ効率と演算効率を向上させるために開発されたものであり、トランジスタレベルのハードウェアに組み込まれているという事実は、新たなワークロードとハードウェア設計の密接な連携を反映している。ソフトウェア要件に関する想定は、ハードウェアが急速に変化するワークロードパターンに適応するにつれて、短期間でシリコンに組み込まれていく。 同様に、CUDAエコシステムにおける専用ライブラリであるFlashAttention-3は、最新のNvidiaアーキテクチャで導入されたLLM最適化ハードウェアプリミティブを活用することで、トランスフォーマーベースの学習と推論を高速化している。これは、動作対象ハードウェアに関する深い知識に基づいて記述されたソフトウェアであり、メモリ操作と計算処理を並列化します。GPUメーカーとソフトウェアエコシステム間の共同設計のペースは、この分野におけるハードウェアとソフトウェア開発の緊密な統合を示している。かつて数十年を要したソフトウェアのニーズと専用シリコンの間のフィードバックループは、今や数年に短縮されている。 物理的な制約が強い場合、ハードウェアへの意識は最適化のための手段から戦略的な手段へと変化する。しかし、パフォーマンスがハードウェア固有の機能の活用にますます依存するようになると、それらの機能を制御する者が優位に立つことになる。共同設計は価値を生み出すが、同時に依存関係も生み出す。パフォーマンスへの道がベンダー固有のシリコンを通る場合、抽象化レイヤーを誰が制御するかという問題は、市場支配力の問題となる。 半導体ベンダーは、顧客を自社ハードウェアに囲い込む強い動機を持っている。ベンダー固有の機能を使用するかどうかというアーキテクチャ上の選択はすべてが賭けであり、今日のパフォーマンスを犠牲にして将来の柔軟性を確保するか、パフォーマンスを犠牲にして選択の自由を維持するかの選択となる。抽象化は最小公倍数効果に直面し、すべてのハードウェアプラットフォームに共通する機能はコモディティ化されたものだけとなる。限られたハードウェアリソースからパフォーマンスを引き出すには、最新かつ最高のハードウェア機能を活用するための抜け道が必要となる。これらの機能は、移植可能な抽象化の外、ベンダー固有の扉の向こう側に存在する。 機械学習の分野では、XLA、TVM、Tritonがこの緊張関係を典型的に表している。これらのコンパイラ技術は、高レベルモデルをハードウェア固有の実行可能コードに変換することで、PyTorchなどのフレームワークが比較的ハードウェアに依存しない状態を維持し、多様化するハードウェア環境において選択肢を確保できるようにしている。Googleは、LLMが主流になる何年も前に導入した自社開発のTPU（テンソル・プロセッシング・ユニット）と呼ばれるチップ上でLLMを実行するために、XLAに多額の投資を行ってきた。彼らはシリコンとコンパイラの両方を構築した。抽象化レイヤー自体が、独自のハードウェアを活用してパフォーマンスを向上させつつ、ソフトウェアスタックを外部のチップサプライヤーへの依存から切り離す戦略的な資産となった。 しかし、制約条件下でパフォーマンスを最大化するためにハードウェアの認識が重要であるにもかかわらず、その影響は一様ではない。共同設計には、エンジニアリング作業、人的資本、そして複数の技術分野にわたる長期的なメンテナンスにおいて、多大なコストがかかる。このコストを償却できるのは、これらのアーキテクチャ上の選択が持続的にサポートできる場合に限られる。結果として、ハードウェア認識を最大限に活用できるのは、規模、資本、そして長期的な計画期間が既に存在する分野に集中する傾向がある。そして、この分野で最も有利な立場にあるのは、パブリッククラウドプロバイダーである。 豊かさの後のクラウド クラウドコンピューティングは、大規模な運用には物理インフラの所有が不可欠だった時代に登場した。導入にはサーバー、ネットワーク、電力契約などに数百万ドルもの費用がかかり、キャパシティプランニングには多額の資本が必要だった。また、企業はリソースの利用率が低いリスクを負わなければならなかった。 クラウドコンピューティングの主要な価値提案の一つは、計算リソースを豊富かつ代替可能に見せることだった。弾力性はクラウド利用者にとって当然の前提となり、キャパシティプランニングを後回しにできるほどになった。開発者はピーク需要に対応するためにリソースを準備する必要がなくなり、クラウドプロバイダーが提供する事実上無限のサーバー群から必要なリソースを引き出し、使用した分だけ料金を支払うだけで済むようになった。 このモデルは、必要な時にインフラが十分に利用可能であること、価格が予測可能であること、そして規模の経済性を活かせるプロバイダーが遊休設備の利用リスクを吸収するという暗黙の前提に基づいていた。規制はなかったものの、数十年にわたる継続的なハードウェア改良による豊富な供給量と、ハイパースケールクラウドプロバイダー間の競争が相まって、これらの前提は概ね維持されてきた。 今日のGPU、メモリ、電力といった物理的な制約のある世界では、その均衡は崩れつつある。弾力性はもはや無条件ではない。供給は迅速に対応できず、需要は衰える兆しを見せない。供給と需要の両方が非弾力的になると、供給量と価格は想定される環境条件ではなく、不確実性の要因となる。 クラウドプロバイダーはこれまで概ね製品の価格改定を避けてきたが、実際には使用量に応じた課金ではなく、割り当て量に応じた課金を行っている。容量へのアクセスは、クラウドプロバイダーとの事前契約、最低利用額契約、長期契約によって、いわば順番待ちの列に並び続けることがますます重要になっている。柔軟性は、可用性と商用契約に左右されるようになった。 物理的な制約がある状況下では、クラウドプロバイダーはインフラサービスプロバイダーというよりも、むしろ資本配分者に近い存在と言える。その規模の大きさによって、希少なリソースへの優先的なアクセスと価格設定が可能となり、さらにリソースを自社で開発する選択肢も得られる。マクロレベルでは、リソースの調達を一元化し、下流のクラウド顧客にアクセスを再分配すると同時に、大規模なユーザーベース全体でリスクを分散させる。 クラウドコンピューティングは、システムから設備投資をなくしたわけではない。むしろ、設備投資を集中させたのだ。リソースが豊富にある時代には、その集中はほとんど目立たなかったが、リソースが不足する時代には、それが顕在化する。クラウド自体は依然として存在するが、その役割は変化した。物理的な制約に対する仮想的な緩衝材から、そうした制約の中でリソースを割り当てるためのメカニズムへと変化したのである。 現実の厳密さ クラウドが物理的限界に対する緩衝材として機能しなくなるにつれ、それらの限界はソフトウェアシステム自体の中に再現される。デナードのスケーリングが鈍化するにつれて、複雑さがハードウェアからソフトウェアへと移行したのと同様に、今度はリソース不足の問題がクラウドインフラストラクチャからより高レベルのソフトウェアへと押し上げられていく。何を抽象化し、何を構築し、何を最適化するかという決定は、コスト構造、利益率、そして競争優位性を直接的に左右する。これらの決定をもはや後回しにはできない。 これは理論上の話ではない。電力、メモリ、コンピューティングといった分野では、需要が供給をますます上回っており、既にプレッシャーがかかっている。リソースの競合はもはや一時的な異常事態ではなく、エンジニアは日々の開発作業において、割り当てやレート制限に直面することが増えている。これらは、意図的なアーキテクチャ上の決定を必要とするトレードオフを迫られる、不均衡のシグナルだ。 すべての製品やビジネスがこうした限界で運用されているわけではない。多くの企業は、収益に対するコンピューティングコストが安価で、パフォーマンスが許容範囲内であり、規模が物理的な制約よりも人やプロセスによって左右されるような環境で事業を展開している。このような状況では、抽象化に注力し、より上位のボトルネックに焦点を当てることが合理的な判断となる。しかし、こうした状況は常に変化する。ワークロードが進化するにつれて、かつては当然と思われた前提が崩れることがある。アーキテクチャ上の決定は、将来の顧客需要、技術進歩、そして構造的な優位性がどこから生まれると予想されるかといった点に対する、一種のコミットメント、つまり賭けなのである。 アーキテクチャ設計は、物理的な制約と組織の意図とのインターフェースだ。基本原理から考えることで、制約について論理的に考察し、理想ではなく現実を直視したシステムを設計することができる。アーキテクチャをエンジニアリング部門に委任する技術的な決定事項として扱う組織は、暗黙のうちに、現在の抽象化を形作った環境が今後も存続するという賭けをしていることになる。すべてのシステムには、それが構築された世界に関する前提が組み込まれている。重要なのは、世界が変化する前に、それらの前提を検証することである。

皆さんこんにちは、Product Designerの保川です。春らしい季節になってきましたね。 今日はプロダクト開発を進めるにあたり、私たちが顧客をどのように捉え、インサイトを得ているのかお話ししたいと思います。 B2Bの顧客理解はなぜ難しいのか？ 決める上司と使う部下 組織の構造に埋もれがちなユーザーペイン 業務には沢山のしがらみと感情がある 「点」ではなく「面」で捉える難しさと醍醐味 「生産構造×業種」で見えてくる調達業務の奥深さ 見積は手段、本当に解決したい「手前の悩み」 ペルソナは必ずしも正解ではない アーキタイプとは 誰か、よりどう動くか 最強のリソースは社内から 現場で決めて、動く 他者のレンズを通して顧客理解を深める デザイナーは「想い」をつなぐ架け橋 B2Bの顧客理解はなぜ難しいのか？ B2Bプロダクト業界においてよく言われるのが、B2Cと比べて「ユーザーのインサイトが取りにくい」ということです。インタビューのお返しにギフトをわたすこともできないし、Eメールキャンペーンも通用しません。でもそれだけではないです。 決める上司と使う部下 B2Bはなぜユーザーインサイトを得ることが難しいのか。それは、意思決定者（購買者）とユーザーは別物である、ということが一つ大きな要因だと考えています。 例えば、プロダクトを購入する意思決定者はマネージャー以上、もしくは小規模な会社であればCEOであったりします。しかし、実際のユーザーは一般社員の場合も多い。この両者は、プロダクトを全く異なる目線で見ています。 意思決定者は、投資や説明責任、コスト削減の視点からプロダクトを評価します。対して、ユーザーは、日々の仕事の成果やミスの有無、効率の観点からプロダクトを見ます。この視点の違いこそが、プロダクトが現場で「詰む」原因になります。 組織の構造に埋もれがちなユーザーペイン ユーザーは意思決定者から、「会社の意向だからこれ（プロダクト）を使って欲しい。」といきなり言われるかもしれません。ユーザーのペインは会社の構造や政治によってうまく意思決定者に伝わらないかもしれません。そして、プロダクトのユーザーの思いは意思決定者が主となる会議などの表舞台には一切出てこないかもしれません。 そうなると、プロダクトをユーザーが普段どのように使い、何に使いにくいと感じているのか、そしてどんな潜在ニーズがあるのか。そんな声は当然埋もれてしまいます。 立場やバイアスというノイズが介在するため、ユーザーと同じ景色（ビュー）を見ることは想像以上に困難である 業務には沢山のしがらみと感情がある また、業務において、ユーザーは様々なしがらみにとらわれています。例えば、彼らは単にプロダクトを使って行う仕事だけをしているわけではないということ。まず、プロダクトを使う仕事がそもそもメインの仕事なのか？例えば調達業務であれば、1日3件調達する人と、50件調達する人では、工程や効率への要求が大きく異なります。また、1件において何品目扱うかによって、まとめて編集したいのか、保存が大事なのかなども変わってきます。 さらに、ユーザーの仕事にまつわる上司や同僚からの期待、プレッシャー、など様々な感情的なタスクもこなしている可能性があります。そして、それはユーザー自体が気づいていない部分でもあったりするのです。 「点」ではなく「面」で捉える難しさと醍醐味 実際のユーザーを理解するには、彼らだけでなく全体を捉えることも重要です。誰が、どんな思いをもち、どんな関係で仕事をしていて、どんな仕事の一環でプロダクトを使ってくれているのか。そして彼らはどういう人達と協働しているのか。また、意思決定者とはどんな関係性にあるのか。（ここまでやるのは本当に大事、ですが、難しい！） だからこそ、B2Bのユーザーインサイトを得ることは難しく、とてもチャレンジングです。けれども、それこそが醍醐味です。 ユーザーの声が埋もれがちだからこそ、Product Designerはユーザーインサイトを様々な角度から取りに行く必要があるし、そうしなければ、本当にユーザー目線のプロダクトを作ることができなくなってしまう、重要な役目を果たしています。 「生産構造×業種」で見えてくる調達業務の奥深さ 私はキャディに入社したときに、「調達業務」とは何か？すら全く知らない状況でした。そこで、手当たり次第に製造業の動画をあさっていたところ、同僚が社内に調達経験がある人が複数いることを教えてくれました。 私は、早速アポをとり、調達の業務についてインタビューを6人のユーザーに行いました。そこで、同じ調達といっても量産と少量多品種によって大きく彼らの仕事内容や業務の見方が異なることがわかりました。 見積は手段、本当に解決したい「手前の悩み」 例えば、量産においては「見積業務は判断材料に使える材料」「なぜこの価格なのかの説明責任を果たすもの」であったりするのに対して、少量多品種においては、「下流の流れをとにかく止めないために調整するもの」であったり。当初の私は、「調達の人って見積依頼をかけ、条件が変わったら再見積を行い、価格の合意をするのだろう。」という漠然とした理解がありましたが、インタビューを通して、調達担当の方が本当に解決したいのは、見積を取ることではなくて、もっと手前の状況を整えることだということを理解しました。 そして、最も興味深かったのは、それが生産構造だけでなく、業種においても大きく異なるということです。例えば、プラントを作るくらいの規模の調達と、治具の調達とでは、規模も、個数も異なるため、気にする部分も全く違う。だから、調達のバラエティは生産構造×業種分あるとも言えます。 ペルソナは必ずしも正解ではない アーキタイプとは 一般的に、ユーザー理解といえば、ユーザーインサイトから具体化したユーザー像（ペルソナ）を作ることが推奨されますが、特にキャディのプロダクトにおいては必ずしもその必要はないと考えています。先に述べた理由が大きいですが、業種や製造形態による違いで、課題も意思決定構造も大きく変わるため、「XX歳、製造現場出身調達」のようなペルソナは機能しにくいです。 代わりに、役割や製造構造に応じた一定のユーザーグループであるアーキタイプの方が相性がよいと考えています。 アーキタイプとはペルソナよりも広い概念であり、「行動パターン、動機、目標」にフォーカスを当てたユーザー分類です。 誰か、よりどう動くか B2B、特に生産構造×業種の数だけ変数のある製造業においては、具体的な「個人（Who）」を描写するよりも、「どういう状況で、なぜ動くのか（Why,How）」という行動原理で捉えたほうが、ユーザーへの解像度は圧倒的に高まります。 私たちのプロダクトには、具現化したユーザー像を満足させる以上のプロダクトの価値があると考えています。だからこそ、この複雑なアーキタイプを深く理解し、それぞれの構造に最適化された価値を届けられるよう、今以上に現場の解像度をとことん上げる必要があります。 製造構造と業種の数だけ解像度を上げるなんて、そんな簡単な話じゃないんじゃないの？と思われるかもしれません。でも、キャディなら可能だと思っています。それは、社内リソースが強力だからです。 最強のリソースは社内から キャディには祖業であるManufacturing事業を含め、何百人の顧客と関わったプロフェッショナルたちが多くおり、彼らから学ぶことがものすごく多いです。顧客と関わるSales、CSの一人ひとりの頭の中には解像度の高い顧客（意思決定者並びにユーザー）がいて、彼らのレンズを通して顧客を理解することが最も近道であり、有力な情報収集になると考えています。 現場で決めて、動く これこそがキャディの強みだと私が考えていることの一つは、ビジネスサイドからプロダクトフェーズまで、一丸の意識が強い、ということです。例えば、直接CSとコンタクトをとって顧客訪問に同席をお願いさせてもらったり、定例会議に参加させてもらったり、ということが現場レベルでできます。CSの言葉を借りて言えば「こういう現場レベルで何をやる・やらないの判断ができるのは強い。」のです。なぜなら、個々の主体性と責任で物事を推進しているからです。 これこそまさに、キャディがスピード感と一体感を持って仕事ができる現場である所以なのかもしれません。 他者のレンズを通して顧客理解を深める また、先人たちのお陰で顧客のニーズが定性データとして共有される仕組みも社内では整っています。こういった取り組みは、プロダクトの末端にいるユーザーのインサイトを様々なステークホルダーを経由して、異なる角度から得られる、大事なインサイトです。 こういった断片的な情報の塊を集めてユーザーのインサイトはより分厚いものになっていくのだと思います。 また、キャディには「1日検証会」というものがあり、そこでは潜在的なユーザーに実際にプロダクトを触ってもらう、という機会もあります。こういった機会を通して口頭ではわからないユーザーの行動パターンや、ITリテラシー、宝の山となるインサイトを得ることもできました。 デザイナーは「想い」をつなぐ架け橋 Product Designerの役割は、インサイトをつなぎ、構造として再解釈することだと考えています。ユーザーは一人ひとり異なる存在であり、その背景にはパーソナリティや経験など多くの要因があります。 だからこそ、n=1の事象をそのまま扱うのではなく、抽象化しながら意味を見出していく必要があります。 また、私は社内の人たちの仕事を理解することもProduct Designerとしては重要な部分であると思っています。キャディのメンバーを知れば知るほど、プロダクトに熱く、顧客を大切にしている人たちなのだと感じます。そして、それ以上に、ビジネス文脈を含んだユーザーのニーズが色濃く見えてきます。 明確な正解があるわけではありません。だからこそ、プロダクトに関わる一人ひとりの想いや情報を取り続けながら、仮説と検証を繰り返していく。そのプロセス自体が、この仕事の難しさであり、面白さだと感じています。

Release notes used to be one of those tasks everyone agreed was important, but nobody really owned. We’d ship a release, someone would scramble to collect changes from developers, and eventually a Markdown file or sometimes an Excel sheet would appear usually incomplete, sometimes outdated, and almost always inconsistent in tone and structure. A few months ago, I got tired of that loop and built an automated release note generation system. It’s now part of our release workflow, and more importantly, it gave QA a much more reliable way to verify changes. The Problem The Idea The Solution How It Works 1. Release branch creation 2. Tag generation 3. Slack trigger 4. Devin AI runs the playbook 5. Version diff analysis 6. Release note generation 7. Slack delivery The Prompt We Use Impact QA got a reliable way to verify changes Better visibility for stakeholders Consistency across releases Reduced ambiguity Lessons Learned 1. Version comparison is the foundation 2. Risk analysis adds real value 3. Fully automated doesn’t mean zero oversight Closing Thoughts The Problem Before automation, release notes were assembled manually. The process looked roughly like this: Developers would drop notes in Slack, PR descriptions, or sometimes directly into Excel Someone (usually from QA or a PM) would try to consolidate them Important changes were sometimes missed Technical changes were either too vague or too detailed There was no consistent structure across releases The biggest issue wasn’t just the time it was lack of reliability. QA engineers often had to double-check commits anyway because: Some changes weren’t documented The impact of changes wasn’t clear Dependencies between components weren’t not visible So instead of helping QA, release notes became something they couldn’t fully trust. The Idea Instead of asking humans to summarize changes after the fact, we shifted the source of truth: Let the system generate release notes directly from version differences. That meant: Comparing actual code changes between releases Using commit history and PR data as inputs Letting AI handle summarization and structuring This removed the dependency on manual input and made the process deterministic. The Solution We built an automated pipeline that generates release notes by comparing: The current release branch/tag The previous release tag From that diff, the system collects: Commits Pull requests Code changes PR descriptions and comments Then an AI agent (Devin) processes that data and generates: Structured release notes Categorized changes (features, fixes, etc.) Risk analysis for QA Output in both English and Japanese Everything is posted back into Slack as a .md file. How It Works Here’s the workflow we run in production. 1. Release branch creation We follow a simple convention: release/{version} This becomes the anchor point for the release. 2. Tag generation A release tag (e.g., v2.3.0) is created. This allows us to: - Identify the current version - Locate the previous version tag - Establish a clear comparison range 3. Slack trigger Once the release tag is created, a GitHub Action sends a request to a Slack webhook that’s wired into a Slack workflow. That workflow posts a message in Slack and tags @devin with the playbook macro, which then kicks off the automation. Additionally, we kept a manual fallback anyone can trigger the same process by tagging @devin with the playbook macro directly in Slack. This is useful in cases where we want to regenerate notes or run it outside the standard release flow. This setup keeps everything inside the team’s existing workflow while removing any manual steps no one needs to remember to run scripts or trigger jobs separately. @Devin !generate_bilingual_release_notes !deep ========================= Repository : example-repo Release branch : release/v17.3 ========================= 4. Devin AI runs the playbook Devin executes a predefined prompt that drives the entire process. It: - Parses version information - Finds the previous release - Analyzes commits, PRs, and diffs - Combines intent (PR descriptions) with actual code changes - Generates structured, bilingual release notes - Performs risk and dependency analysis 5. Version diff analysis This is the core step. The system: Lists all commits between two versions Maps commits to PRs Extracts relevant file changes Identifies impacted modules This ensures the output is based on what actually changed not what someone remembered. 6. Release note generation The output is a structured Markdown file with: Summary Features / Enhancements / Bug Fixes / Technical Improvements PR list Risk & dependency analysis It also includes: English version Japanese version (collapsible section) 7. Slack delivery The generated .md file is posted back into the same Slack thread. This keeps the entire release conversation in one place and easy to track. The Prompt We Use This is the core prompt that powers the system. It’s doing most of the orchestration work: # TASK: Generate Bilingual Release Notes File with Risk Analysis ## 1. ROLE & GOAL You are an expert technical writer and AI development agent with the ability to read and understand code. Your goal is to autonomously generate comprehensive **bilingual (English and Japanese)** release notes, complete with a detailed **risk and dependency analysis** for the testing team, and output the result as a complete Markdown file. ## 2. CONTEXT & ASSUMPTIONS - **Input:** You will be given the repository name and the current release branch name. - **Language Output:** English and Japanese. - **Final Output:** A single Markdown ( ` .md ` ) file. - **Audiences:** - **Primary (main body):** Product managers and stakeholders. - **Secondary (final section):** The Testing Team. - **Project Structure Assumptions:** - Release branches follow the pattern: ` release/{version} ` . - Releases are marked with git tags that follow semantic versioning (e.g., ` v2.0.0 ` or ` 2.0.0 ` ). ## 3. INSTRUCTIONS Follow these steps precisely: 1. **Initial Analysis:** - The **Project Name** is the ` REPOSITORY_NAME ` provided as input. - The **Current Release Branch** is the ` RELEASE_BRANCH_NAME ` provided as input. - verify above name is actually match with repository name as project name before writing to output file. 2. **Determine Versions:** - From the Current Release Branch name, parse the **Current Version**. - Scan the repository's git tags to find the **Previous Version** tag immediately preceding the Current Version. This is your comparison starting point. 3. **Synthesize Change Information (Crucial Step):** - To build a complete understanding of each change, analyze three sources between the Previous Version and the Current Release Branch: i. **Commit Messages & PR Descriptions:** To understand the developer's *intent*. ii. **Actual Code Diffs:** To understand what was *actually* implemented. iii. **Synthesis:** Combine intent with ground truth. While synthesizing, pay close attention to inter-module dependencies and the potential blast radius of changes to inform the risk assessment. 4. **Collate Pull Requests:** - Gather a complete list of all Pull Request titles and numbers that were merged between the **Previous Version** and the **Current Release Branch**. This raw list is for inclusion in its own section. 5. **Categorize and Rewrite for Stakeholders:** - Group the synthesized changes from Step 3 into the primary categories: ` New Features ` , ` Enhancements ` , ` Bug Fixes ` , and ` Technical Improvements ` . - Rewrite each item for the product/stakeholder audience, focusing on user benefits. **You must generate this content in both English and Japanese.** 6. **Perform Risk and Dependency Analysis for Testing Team:** - For each major impacted area identified in your synthesis, perform the following detailed analysis: - **Risk Level:** Assign a risk level: `High`, `Medium`, or `Low`. Base this on the change's complexity, its centrality to the application (e.g., changes to authentication are `High` risk), and the potential for unintended side effects. - **Components and Dependencies:** Clearly state the primary component that was changed. Then, list other key components or features that depend on it. - **You must generate this entire analysis in both English and Japanese.** 7. **Assemble the Final File:** - Format all generated bilingual content into a single Markdown file named ` RELEASE_NOTES_{Identified_Version}.md ` . This file is your final output. - Set the release date to today's date: **August 28, 2025**. ## 4. OUTPUT FORMAT Produce a single Markdown file named ` RELEASE_NOTES_{Identified_Version}.md ` . The content must strictly follow this bilingual template, with the Japanese section nested inside a collapsible ` <details> ` tag. # Release Notes: {Project _ Name} v{Current _ Version} **Generate Date:** August 28, 2025 ## Summary A brief, one-to-two-sentence overview of the most important changes included in this release version. --- ## ✨ New Features - [A clear, benefit-oriented description of the first new feature.] - [Description of the second new feature.] ## 🚀 Enhancements - [Description of an enhancement to an existing feature.] - [Description of a performance or UI improvement.] ## 🐛 Bug Fixes - [A simple explanation of the bug that was fixed, e.g., "Fixed an issue where reports would fail to generate for users in the 'Guest' role."] - [Another bug fix description.] ## 🛠️ Technical Improvements - [A high-level summary of a technical or backend change, e.g., "Upgraded the database engine to improve overall application performance and security."] - [Another technical improvement summary.] --- ## 📦 Included Pull Requests A complete list of Pull Requests included in this release. - [PR #{number}] {PR _ Title} - [PR #{number}] {PR _ Title} - [PR #{number}] {PR _ Title} --- ## 🧪 For the Testing Team: Risk & Impact Analysis ### High-Risk Areas - **[Impacted Module/Feature 1]:** [Brief English description of the change.] - **Risk Level:** ` High ` - **Dependencies:** [List of dependent components, e.g., "User Profile, Reporting Module, API v2"] ### Medium-Risk Areas - **[Impacted Module/Feature 2]:** [Brief English description of the change.] - **Risk Level:** ` Medium ` - **Dependencies:** [List of dependent components] ### Low-Risk Areas - **[Impacted Module/Feature 3]:** [Brief English description of the change.] - **Risk Level:** ` Low ` - **Dependencies:** [List of dependent components] --- < details > < summary > 🇯🇵 日本語のリリースノート (Japanese Release Notes) </ summary > # リリースノート: {Project _ Name} v{Current _ Version} **作成日:** 2025年8月28日 ## 概要 (Summary) このリリースに含まれる最も重要な変更点の概要（1〜2文程度）。 --- ## ✨ 新機能 (New Features) - [新機能1の分かりやすく、メリット中心の説明。] - [新機能2の説明。] ## 🚀 機能改善 (Enhancements) - [既存機能の改善に関する説明。] - [パフォーマンスやUIの改善に関する説明。] ## 🐛 不具合修正 (Bug Fixes) - [修正された不具合の簡単な説明。例：「ゲストロールのユーザーがレポートを生成できない問題を修正しました。」] - [その他の不具合修正に関する説明。] ## 🛠️ 技術的改善 (Technical Improvements) - [技術的な変更やバックエンドの変更に関する概要。例：「システムのセキュリティを向上させるため、コアサーバーの依存関係を更新しました。」] - [その他の技術的改善に関する概要。] --- ## 📦 含まれるプルリクエスト (Included Pull Requests) このリリースに含まれるプルリクエストの完全なリストです。 - [PR #{number}] {PR _ Title} - [PR #{number}] {PR _ Title} - [PR #{number}] {PR _ Title} --- ## 🧪 テストチーム向け: リスクと影響範囲の分析 (Risk & Impact Analysis) ### 高リスク領域 (High-Risk Areas) - **[影響を受けるモジュール/機能1]:** [変更内容の簡単な日本語説明。] - **リスクレベル (Risk Level):** ` 高 ` - **依存関係 (Dependencies):** [依存するコンポーネントのリスト] ### 中リスク領域 (Medium-Risk Areas) - **[影響を受けるモジュール/機能2]:** [変更内容の簡単な日本語説明。] - **リスクレベル (Risk Level):** ` 中 ` - **依存関係 (Dependencies):** [依存するコンポーネントのリスト] ### 低リスク領域 (Low-Risk Areas) - **[影響を受けるモジュール/機能3]:** [変更内容の簡単な日本語説明。] - **リスクレベル (Risk Level):** ` 低 ` - **依存関係 (Dependencies):** [依存するコンポーネントのリスト] </ details > --- ## ACTION REQUIRED Execute the analysis and generate the bilingual release notes file as the final output. **REPOSITORY_NAME:** ` {{Repository}} ` **RELEASE_BRANCH_NAME:** ` {{Release branch}} ` ## Forbidden actions do not push to any branch In practice, the most important part is step 3 combining intent with actual implementation. That’s what prevents misleading summaries. Impact QA got a reliable way to verify changes Instead of digging through commits from scratch, QA now uses release notes as a baseline for double verification. They can: Cross-check listed changes against actual behavior Focus on high-risk areas first Understand dependencies between components This didn’t just make things faster it made validation more structured and less error-prone. Better visibility for stakeholders Product managers get clear, structured release notes automatically. The categorization is consistent, and the language is adapted for non-engineering audiences. Consistency across releases Every release note now follows the same structure: Same sections Same formatting Same level of detail This makes it much easier to scan and compare releases over time. Reduced ambiguity We used to see a lot of questions like: Was this included in the release? Did we fix this issue? Is this area risky? Now those answers are usually already in the release notes. Lessons Learned 1. Version comparison is the foundation The biggest improvement came from switching to version-based diffing. Once we relied on: Previous tag → Current release Everything became more accurate and complete. 2. Risk analysis adds real value Release notes alone are useful, but adding risk analysis made them actionable. QA can immediately identify: Where failures are more likely What areas need deeper testing Which components are interconnected Recommended Test Focus : Suggest whether this change requires deep functional testing, broad UI regression, or specific edge-case validation (e.g., "Focus on data integrity for Guest roles" or "Perform wide CSS regression across mobile viewports"). 3. Fully automated doesn’t mean zero oversight We still review release notes occasionally, especially for larger changes. But instead of writing everything manually, we’re reviewing something that’s already mostly correct. Closing Thoughts This system isn’t complex. It’s mostly: Git diffing A structured prompt A simple automation flow But it changed how we handle releases. Release notes went from being an unreliable afterthought to something QA can actually use for validation. If you’re still writing release notes manually, start with version comparison. That alone solves most of the problem. The rest is just refinement.

市役所からのお知らせです。 ＿人人人人人人人人人人人人人人人人人人人人人人人人人人＿ ＞　 この記事では IEEE754 偶数丸めを仮定しています！　＜ ￣ＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹ￣ 述語によっては丸め方向が大事なものがあるのですが、いちいちお断りするの大変ですからね。世は大省エネ時代です。 こんなみなさまに読んでいただきたい！ ところでみなさま！ 初めて算術回路を学んだときの感動を憶えていらっしゃいますか？ みなさま「足し算なんて私の知っている筆算を回路に落とすだけでしょう、私は天才！人生楽勝！」 みなさま「……高さ (= 回路の最長路長) O(log w) ！？」（w はワード長） ご存知なかった方はこの機会にそちらもチェックしていただきつつ、まずは私の一勝ということでね。 そういえば算術回路についての名著『アルゴリズムイントロダクション』の第2版 第3巻（今手に入るのですかねこれ）に書いてありました。第3版で廃止されたのですが、時代ですね🙃 ともあれこういうのまだまだやりたいではありませんか！ 浮動小数点数 & 計算幾何 𝐼𝑠 𝐴𝑙𝑙 𝑌𝑜𝑢 𝑁𝑒𝑒𝑑（文法ミス）です。やっていきましょう！ Section 1: 適応的精度 (Adaptive Precision) の概要 適応的精度 (Adaptive Precision) は、状況に応じて計算精度を徐々に上げていくことで、最小限のコストで厳密な不等式判定を可能にする手法で、丸め誤差をうまく再利用するのがポイントです。 Adaptive Precision の詳細については Shewchuk (1997) に詳しいです。みなさまもぜひです。 適応的精度（Adaptive Precision）を知ったきっかけ 3D CAD といえば B-Rep (Boundary Representation) です。要はトポロジー（面などの接続関係）と、ジオメトリー（それらの方程式）を別で管理するということですね。 これがまた大変です。決まった形をしていませんから、機械学習がとても大変です。（実はここ最近 B-Rep 向けの機械学習もアツいのですがそれはまた別のお話🖐️） というわけでみんな大好きルールベースになるわけですが、これアルゴリズムをある程度頑健にしておかないとデバッグが難しいのですよね。そのへんでいろいろ調べていたら知ってしまった†深淵†のひとつです。私の右目が疼く前に次のセクションへ GO! です。 適応的精度（Adaptive Precision）の動機は？ 計算幾何あるあるをご紹介しましょう。 たとえば、2 次元の与えられた 3 点 A, B, C の配置がこの順に反時計回り、時計回り、共線（同一直線上）のどれであるかを判定する問題を考えてみましょう。 みなさま「こういうのは行列式を使えばよいのですよね。数学に詳しすぎて照れてしまいますね」 みなさま「あれ、こ〜れ境界値周りの挙動が一貫していなかったらぶっ壊れますでございますわ〜☀️☀️☀️」 共感していただけましたでしょうかね。要は別に微妙な結果がどちらに転ぶのかをすごく気にしている訳ではなくて、大事なのは ズレるのはよいとしてどちらに転ぶかが一貫していなかったら全体がぐちゃぐちゃになってしまう ということです。 反時計回りであるかどうかなど、Yes/No が定まるものを 述語(predicate) といい（例：反時計回りか？円の内側か？など）、これを厳密に判定する手法は 厳密幾何計算 (Exact Geometric Computation, EGC) と呼ばれていて、数値そのものを正確に計算する厳密算術計算 (Exact Arithmetic Computation) とは区別されます。符号などの判定だけを厳密にするので、数値全体を厳密化するより軽いのがポイントです。 せっかくですから、 Kettner, Lutz, et al. (2008) から印象的な図表をいくつか引用しましょう。 印象的な図表 1 まずは反時計回り・時計回り・共線判定がいかに数値的に不安定であるのかを見ていきましょう。 キャプションにある 3 点 A, B, C を、ほんのちょっとだけ動かした点 A', B', C' が、どちら向きに並んでいるかを浮動小数点数演算で判定した結果です。 反時計回りになっている 👉 青色 時計回りになっている 👉 赤色 共線になっている 👉 黄色 ちなみに黒色の細い対角線は、真に共線になるべきところです。え！？！？ もはや絨毯として販売できそうなカオスっぷりです。 印象的な図表 2 次は、反時計回り・時計回り・共線判定が不安定なせいで、いかに派手に幾何アルゴリズムが \ﾄﾞﾝｶﾞﾗｶﾞｯｼｬｰﾝ💥/ するのかを見ていきましょう！ むかしむかしある座標平面に、点 p₁ さんと、点 p₂ さんと、点 p₃ さんと、点 p₄ さんが、この順に反時計回りの凸四角形を構成しながら暮らしていました。 おばあさんが川で洗濯をしていると、大きな桃🍑が流れてきました。 その桃🍑を切ると、なんと点 p₁ のすぐ右に点 p₅ がおぎゃあ、おぎゃあと……… ってこれいつまでやればよいでしょうかね。止めないと私無限に続けますよ！？！？ そんなことより凸性です！ 点 p₅ を追加した結果は (a) の通りです。 点 p₁ と点 p₅ の差が丸め誤差に吸収されて、ちょっと凹んでしまっていまね。ウーンム…… みなさま「こんなん誤差やん。うおｗ」 私「1εを笑うものは1εに泣きますよ。」 ここで (b) の拡大図をご覧ください！ 点 p₆ を追加するとあらふしぎ。前提が壊れているのでぐ〜〜〜〜っちゃぐちゃです。 (c) は細かい実装バリエーションの結果です。わかる人にだけわかるご説明をすると、点 p₆ から「見える」edge は p₄p₅ と p₁p₂ (のみ)で、どちらを先に発見するかで結果が変わるというわけですね。 これでもう「うおｗ」とは言わせませんよ。 いたるところで大活躍する基本的な述語 4 選！ Orient2d みなさまの記憶力は素晴らしいため、問題を憶えていらっしゃいます。 2 次元において、点 c が直線 ab のどちら側にあるかは次の行列式で決まります。 ところでこれ命名の流派たくさんあって毎回ウーンムとなります。厳密計算の分野における古典的な呼び方はおそらく Orient2d, Orientation2d なのですけれども、たとえば nalgebra では perp (perpendicular product の略？) と呼ばれていたり、私はじめ競プロ経験のある方は ccw (counter-clockwise の略）を使うことが多かったり、単に det と書く方もいらっしゃったりなどです。 Orient3d 3 次元バージョンです。萌え萌えでなくて申し訳ないです。 3 次元において、点 d が平面 abc のどちら側にあるかは次の行列式で決まります。 InCircle 2 次元において、点 d が円 abc の内外どちらにあるかは次の行列式で決まります。 InSphere 3 次元において、点 e が球 abcd の内外どちらにあるかは次の行列式で決まります。 これらの主な用途を挙げておきますね。聞いたことのない方には先着で読み上げ音声をプレゼントです。 アルゴリズム 活躍する述語 凸包構築 Orient2d 線分交差判定・線分群の交差列挙 ( Bentley–Ottmann algorithm ) Orient2d ドロネー三角形分割 Orient2d, InCircle ボロノイ図 の構築 ( Fortune’s Algorithm ) InCircle メッシュの refinement ( Delaunay Refinement ) Orient2d, InCircle 3 次元でも基本的には同様の問題があって、対応する述語が活躍することが多いです。 Adaptive Precision のアプローチ お話がそれましたわ。これらの述語をどういうアプローチで「必要なときだけ厳密に」「お爆速に」行うのかをみていきましょうですわ〜〜〜 大事なことは、 近似計算でも結果が 0 から大きく離れていたら信じて OK （= 推定誤差上界より十分大きい）ということです。 ある精度で近似計算を行います。 誤差上界を評価します。 0 から大きく離れている場合 👉 return 結果 0 に近い場合 👉 精度を上げて 1 行目にもどる or どこかの段階で任意精度計算で厳密な判定を行います。 アッ、まだ帰らないでいただいて…… わかります。 みなさま「ハイハイ、どうせ任意精度(= 多倍長)小数でしょ。┐(´д｀)┌」 私「面白いのはここからです！！！（☝ ՞ਊ ՞）☝」 これでうまくいくのは当たり前ではありませんかと、ええ、うんうんそれは彼氏さんが悪いです。 なんと Adaptive Precision の方法は 動的メモリ確保なし・ほとんど条件分岐なし で行うことができます。しかも 精度を上げて再計算するときには前回の計算の途中結果を使いまわすことができます 。その裏にあるのは、丸め誤差をキレイに分類するための、まるで回路図のような洗練されたアルゴリズムです。 たとえば Orient2d は下図のようになります。 アッ、まだ帰らないでいただいて…… 大丈夫です、私もわかりませんでした。 目標まとめ やりたいのはこちらでしたね。 Orient2d, Orient3d, InCircle, InSphere などの述語を厳密に判定したいです。 境界値に近くない場合は計算が早く終わっていただきたいです。 動的メモリ確保なしです。（従って 普通の任意精度小数は使えません！ ） 条件分岐は必要最低限です。（従って 算術計算なんかで場合分けは使えません！ ） 全部は大変ですから、みなさまがご興味を持っていただけそうなところまでご招待したいと思います。 Section 2: 足し算・掛け算の実装 2 つの浮動小数点数の和や差を、どうやって表しましょうか 2 つの浮動小数点数 a, b の和 a + b や積 ab の正確な値は、1 つの浮動小数点数では表現できません。 しかし！ ここで軽率に普通の任意精度小数を使ってしまうと、たとえば 2¹⁰²³ と 2⁻¹⁰²² の和などはと〜〜〜んでもない長さになってしまいますね。長いものがお好きな方以外は悲しくなってしまいます。 そこで、 和による表現 です。a + b や ab を 2 つの浮動小数点数 x, y の和で表してしまいましょう。といっても何でもアリにしてしまうと後で困るので、上手い条件を課します。a + b や ab の場合は実は x が丸めた値、y が丸め誤差に一致するようにするのがツウなのですが、一旦もう少し一般のお話をいたしましょうか。 a + b と等しい expression 任意精度小数の一般的な表現 有限小数 x に対し、それを浮動小数点数 x₁, x₂, ..., xₙ の総和 x = x₁ + x₂ + ⋯ + xₙ で表したものを x の表現 (Expression) と呼ぶことにしましょう。 そしてしばしば次のような条件を課します。 nonoverlapping 表現 x = x₁ + x₂ + ⋯ + xₙ が nonoverlapping であるという用語を定義していきましょう。 まずは準備です。浮動小数点数 a, b が次のいずれかの条件を満たすとき、a と b は nonoverlapping であるといいます: a の最下位ビットが、b の最上位ビットよりも真に大きい b の最下位ビットが、a の最上位ビットよりも真に大きい a = 0 b = 0 表現 x = x₁ + x₂ + ⋯ + xₙ は、そのどの相異なる 2 項も nonoverlapping であるときに nonoverlapping であるといいます。 「ビットの範囲が重なっていない」と言い換えるとわかりやすいかもでしょうかね。 nonoverlapping の概念図 nonadjacent 次は、表現 x = x₁ + x₂ + ⋯ + xₙ が nonadjacent であるという用語を定義していきましょう。 まずは準備です。浮動小数点数 a, b が次のいずれかの条件を満たすとき、a と b は nonadjacent であるといいます a の最下位ビットが、2b の最上位ビットよりも真に大きい b の最下位ビットが、2a の最上位ビットよりも真に大きい a = 0 b = 0 表現 x = x₁ + x₂ + ⋯ + xₙ は、そのどの相異なる 2 項も nonadjacent であるときに nonadjacent であるといいます。 「ビットの範囲の間に 1 bit 以上隙間が空いている」と言い換えるとわかりやすいかもでしょうかね。 nonadjacent の概念図 みなさま「わざわざ隙間を 1 開ける理由はなんですか？」 わかります。浮動小数点数演算 a + b や ab の結果を丸めた値 x と丸め誤差 y の関係を思い出してみましょう。 計算機イプシロン ε を用いて |y| ≤ (x の最上位ビット) · ε / 2 が成り立ちますね？ はい、一つ隙間が空いているため 𝑣𝑖𝑐𝑡𝑜𝑟𝑦 です。逆にこれ以上開けるのを保証するのは不可能です。 誤差をバッチリ管理して算術演算をする方法 記法 浮動小数点数 a, b に対して、a + b, a - b, ab を丸めた値をそれぞれ a ⊕ b, a ⊖ b, a ⊗ b と表します。 浮動小数点数の和 a + b 簡単のため |a| ≥ |b| を仮定しましょう。すると筆算の様子はだいたいこういう感じですね。実際には a, b, x, y のどれか負になったりもしますけれども、そのあたりはご愛嬌です。 x は浮動小数点数演算でそのままGO!です。y は真の値 x の差 (a + b) - x を丁寧に計算すれば良いですね。具体的には y = b - (x - a) と表すと途中どこにも丸め誤差が生じなくて 𝑤𝑖𝑛 です。👇 疑似コード みなさま「え、あの、 |a| ≥ |b| ってつまりそれを保証するために条件分岐が入りますよね？？？」 ウーンム、痛いところを突かれましたね。しかし実は y = (a - (x - (x - a))) + (b - (x - a)) がそれを解決するのですよ。証明は難しくはありませんが場合わけが多いですから、みなさまのご担当ということでよろしくお願いさせていただいてですね。そのかわり明日の給食当番は私にお任せください🖐️ Expression e と浮動小数点数 b の和 結果となる expression は長さが 1 長くなります。この世界では演算をしても項の個数が減らないという地獄みたいな設定ですからね🫠 e = e₁ + e₂ + ⋯ + eₙ が nonadjacent かつ、「一部に 0 があるかもしれないことを除いて絶対値が単調増加」という前提条件を課して、次の回路で計算すると、実はその性質が保たれます。 Expression 同士の和 e + f ドーーン！Go Bold の精神です。 浮動小数点数同士の積 ab これまた賢いですよね。実は入力 a, b をともに上位ビットと下位ビットに分解するとうまくいきます。というかよく考えたらそうでもしないと精度が足りないのは明らかですよね。（p 桁の正整数と q 桁の正整数の積が常に p + q - 1 桁であるという事実に注意です。） それに注意した上で、足し算のとき同様に、丸め誤差が出ないように少しずつ差を計算していく方針です。疑似コードを追っていただいてもわかるかもしれませんし、難しければぜひとも原典をです。 Expression e と浮動小数点数 b の積 次のような回路で計算できて、項の個数は 2 倍になりますね。 とはいえ論文中のどの述語の実装でも掛け算は浮動小数点数同士でしか行っていませんから、今回必要はないみたいですね。 これで一通り回路のパーツが揃いました！ あとは各述語 Orient2d, Orient3d, InCircle, InSphere を実装していくだけです！ ……というのがまあ地獄みたいな作業なのですよね。 あと念の為注意なのですが、出力される expression の項は 0 を含むことがあります。例えば a + b を浮動小数点数で計算しても全く誤差の出ない場合は y = 0 になりますよね。これをハンドルしようと思うと当然場合分けが出てくるため、意図的に放置して、固定演算だけで済むようにしております。賢いですね。 Section 3: 各種幾何述語の adaptive precision 実装（の方針） 目標の下方修正 Orient2d のみを実装しましょう。 えいやだっていやじゃないですか。—— みつを Orient2d の展開 定義を展開しましょう。 これをそのまま回路に起こした結果がこちらです。 アッ、まだ帰らないでいただいて…… いまから理解できますから、たぶん、4 割くらいは。（あの？） 最初の引き算 まずは入力を引き算して、主要項と誤差項にわかれますね。このとき、 主要項はオーダー O(1)を、誤差項はオーダー O(ε) を持つ とみなしましょう。実際には誤差項は主要項のε倍よりもずっと小さいこともありますが、小さい分にはよいのでこのまま形式的に突っ走っていきましょう！ 次の掛け算 さらに図の左半分と右半分それぞれについて {主要項, 誤差項} と {主要項, 誤差項} の 4 種類の掛け算をして、8 つずつ、16 個の項を導出しましょう。これは図の左から順にオーダー O(1), O(ε), O(ε), O(ε²), O(ε), O(ε²), O(ε²), O(ε³) （左半分だけ記述）を持ちます。あとはこれらを全て足し引きしたものが厳密な答えです。 厳密な答え D 実際に Expression の足し引きを行なったものが D です。いかにこれを計算しないかが大事ですね。以降、さまざまな近似をみていきましょう！ 最も粗い近似 A 浮動小数点数でそのまま計算した結果に相当します。 A の誤差範囲 慣れている方ならおかわり🍚いただけると思いますけれども、Orient2d 唯一の危険ポイントは減算 x₅ − x₆ による桁落ちです。そこで |x₅| + |x₆| の定数倍により評価していきましょう。 こちらが温めておいた誤差限界です🍳（料理番組風） |A| がこの値以上でしたら、sign(A) = sign(D) が保証されます。 え、私は証明を追ったのかですって？ さて、次は A と D の中間の精度の値です。 第2の近似: B' これは正直なところ A とほとんど変わらないので、私はあまり存在意義がわからなかったのですが、なにかご存知の方いらしたら教えていただきたいです。 B’ というのは Expression B の浮動小数点数近似です。 みなさま「そんなの B の O(1) 項を取れば良いだけでしょうそんな、またまたぁ〜〜」 わかります。私もそう勘違いしたせいで無限にお時間が溶けました。ここで扱っている expression というのは、主要ビットから貪欲になるべく長くとったものとは限らないということに注意です。ここで躓かなかった方は 𝑌𝑜𝑢 𝑘𝑛𝑜𝑤 𝑡𝑜𝑜 𝑚𝑢𝑐ℎ、バッドエンドです。 実は論文中（Theorem 23）に、主要項を抽出するのに使えるアルゴリズムが記載されています。詳細はさておき、条件分岐が出てきているのはちょっと悲しいところですね。（ちなみにループは今回固定長なので消せます。） 誤差上界をはこちらです。A とあまり変わらなくて悲しいですね。 第3の近似: C O(ε) のオーダーを持つ項を片っ端から集めていることがわかりますね。 誤差限界はこちらです: これでもどうしようもなければ D を計算するということですね。賢いです。 Section 4: 現代の厳密計算 結局私個人が厳密幾何計算を実装する（ハメになる）機会はなかったのですが、では現代ではもう使われていない技術なのでしょうかね。だとしたら、とても寂しいですね。 最後に、この手の厳密述語 (exact predicate) が現代のライブラリでどう扱われているかを軽く見ます。 CGAL にありましたよ！！ こちら、どなたが使っているのですか！？ CGAL (Computational Geometry Algorithms Library) というライブラリがあります。計算幾何のあらゆる叡智の詰まった老舗の C++ ライブラリなのですが、そこを探してみると、 Predefined Kernels というクラス群が見つかります。これは幾何計算をしたり、幾何的オブジェクトを構築したりするときのカーネルです。 命名規則を見ると、exact predicate と exact construction が見えますね。Exact predicate というのは今回ご説明したように、「述語の yes/no を厳密に判定する」ことで、比較的簡単かつあまり大きなコストがかからないと言われています。（簡単ですか？？？？？？） 一方 exact construction は非常に難しいです。というのも predicate のときのように「誤差を評価してフィルタリング」のようなテクは通用せず、すべてを厳密計算する必要があります。そのうえ 複雑な制約条件により与えられる点は長大な有理数や複雑な方程式で表される からです。「構築した点を基準に構築する」とかにも対応しないといけませんからね。 OCCT にはなさそうですね？？？ CAD の超有名 OSS であるところの OCCT (Open Cascade Technology) もチェックです！ 一応探してみましたが、なさそうな気がします。 根拠列挙ターイム！ OCCT は他の CAD カーネル同様、tolerance ベースで管理を行っていますね。 CAD カーネルは点の構築が大前提のソフトですから、exact predicate もうまく活躍できなそうです。 Tolerance によるヒーリングの技術も発達しているので、それで実は実用上困らないのかもしれません。 実際、非常に繊細で複雑な計算である Boolean 演算でも tolerance ベースで計算していることが、 Boolean Operations の Guide を参照するとわかります。 BTW: 機械学習ってなんぼのもんなんですかね さて、ここまで読んでくださったアルゴ系エンジニアのみなさま、機械学習はお好きですか？ みなさま「機械学習がなんぼのもんじゃい✊💥」 みなさま「私たちの憧れたヒューリ🥒スティックプログラミングいずくにかです！」 え、今日日そんなこと思いませんよって、ぐぬぬぅ…… というか私が☝️でしたというだけなのですけれども、最近は変わりました。 機械学習は、やや矮小化かもしれませんけれども「書かなくていい部分が増えただけ」で、古典的手法のエッセンスは残っている気がするのですよね、少なくとも現時点では。 良いヒューリスティックは大抵「天才的な気づき」から始まるものの、その後はつらいモグラ叩きになりがちです。機械学習は、そのモグラ叩きを「最適化問題」として正面から殴れるのが最高に気持ち良いです！ Transformerのような汎用手法が全盛の今でも、何が本質かを見極めてベクトルを練り上げる工程は、極めて domain-specific です。そこには間違いなく、古典の英知が息づいています。 現実世界には「理論上解けるはずなのに、放置されている面白い最適化問題」が山積みです。その山を、古典の英知と最新の技術で一緒に崩しませんか？ そんな仲間を、我々キャディのチームは待っています😉 speakerdeck.com まとめ 何かをするのに遅すぎるということはありません。 おととい 4/11 は私のお誕生日でした。プレゼント🎁を送れなかったよという方、あとはわかりますね。

こんにちは、Infrastructure Teamの宮本( @m1yam0t0 )と申します。 本記事では、キャディの権限昇格システムの取り組みを紹介します。 目次 目次 はじめに 内製システムから Google Cloud PAM への移行 PAM の利用資格の設定 PAM の運用で工夫していること Slack 通知機能の実装 Devin による利用資格設定の自動化 まとめ はじめに みなさんは、パブリッククラウドの権限はどのように管理されていますか？ IAMでメンバーに必要な権限を付与していますでしょうか？TerraformでIaC管理されていますでしょうか？ キャディでは、最小権限の原則に従って、開発者には閲覧系の必要最低限の権限のみを付与しています。 *1 開発・運用で追加の権限が必要になった場合は、Just-In-Time(JIT) Accessの仕組みで一定期間だけ権限昇格できるようになっています。 開発者が権限を申請し、承認者が承認してはじめて権限が付与されます。 最小権限の原則を徹底することで、昨今利用が広がっているAIエージェントを活用した場合にも、本番環境の権限を持っていないため、誤って操作してしまうリスクを低減できます。 本記事ではこのJIT Access Systemを内製システムから Google Cloud Priviledged Access Manager(PAM) に移行したお話を紹介いたします。 内製システムから Google Cloud PAM への移行 キャディでは、2022年より内製のJIT Access Systemを運用しておりました。 しかし、この内製のJIT Access Systemについて、認可制御に課題があったため、IAM Condition を組み合わせて権限が付与できるように改修を検討していました。 そんな中、Google Cloud PAM のアップデートで、権限のスコープが設定可能になったことを知り、検証をしてみたところ、内製のシステムを改修しづつけるより、効率良く目的を達成できることがわかりました。 IAM release notes  |  Identity and Access Management (IAM)  |  Google Cloud Documentation 上記を踏まえて、以下の理由から、キャディのJIT Access SystemをGoogle Cloud PAMへ移行する価値があると判断し、移行を実施いたしました。 権限のスコープを細かく設定でき、取得する権限を必要最小限に抑えられる Cloud Loggingに監査ログが残るため、通知や監査に活用できる Google Cloudマネージドのサービスであるためメンテナンス不要 PAM の利用資格の設定 Google Cloud PAMでは、取得したい権限のセットを利用資格として定義し、必要な権限に対応する利用資格を選択して申請します。 Terraform Provider が公式で提供 されているため、IaCで管理できます。 利用資格はユースケースごとに複数作成するため、 以下のようなTerraform moduleを定義し、変数を入力することで容易に設定できるようにします。 resource "google_privileged_access_manager_entitlement" "entitlement" { provider = google-beta entitlement_id = var.entitlement_id location = var.location parent = var.parent max_request_duration = var.max_request_duration eligible_users { principals = var.eligible_users } privileged_access { gcp_iam_access { resource_type = var.resource_type resource = var.resource dynamic "role_bindings" { for_each = toset (var.roles) content { role = role_bindings.value } } } } approval_workflow { manual_approvals { require_approver_justification = var.require_approver_justification steps { approvers { principals = var.approvers } approvals_needed = var.approvals_needed approver_email_recipients = var.approver_email_recipients } } } additional_notification_targets { admin_email_recipients = var.notification_emails } requester_justification_config { unstructured {} } } 実際に利用する箇所では以下のようにTerraform moduleを呼び出して定義しています。 申請・承認するユーザを設定できるため、チームによって申請可能な利用資格を設定できます。 module "pam_org_gcs_bucket_read_access" { source = "../../modules/pam" # 利用資格名 entitlement_id = "gcs-bucket-read-access" # Organization, Folder, Project 単位で指定可能 parent = "organizations/$ { local.organization_id } " location = "global" resource_type = "cloudresourcemanager.googleapis.com/Organization" resource = "//cloudresourcemanager.googleapis.com/organizations/$ { local.organization_id } " # 取得したい role を定義 roles = [ "roles/storage.bucketViewer" , "roles/storage.objectViewer" , ] # 申請可能なユーザ eligible_users = [ "group:users@caddi.com" , ] # 承認可能なユーザ approvers = [ "group:approvers@caddi.com" , ] # 最大の申請期間 max_request_duration = "14400s" # 必要な承認の数 approvals_needed = 1 } PAM の運用で工夫していること Slack 通知機能の実装 PAMの通知機能はメール通知のみでSlackへの通知には標準では対応していません。 しかし、既存のJIT Access SystemではSlack通知するようにしていたため、利用者体験が変わらないようにする必要がありました。 そこで、PAMの監査ログの内容をパースしてSlack通知するAPIを実装しました。 以下のような仕組みで動作しています。 Pub/Subを経由して、実装したSlack通知APIに送信 Cloud Loggingに保存されているPAMの監査ログをLog routerでPub/Subに転送 Pub/Subの Push Subscription を使ってCloud Runで動作しているSlack通知APIにHTTP POST 実際の構成図は以下です。 PAM通知機能の構成図 上記のSlack通知APIを利用して、既存システムの使用感はそのままに、SlackでPAMの申請・承認を通知できるようにしました。 PAMのSlack通知 Slack通知の内容についても、利便性を上げるために様々な改善をしています。 承認結果のメッセージを申請したメッセージのスレッドに紐づけて投稿 申請内容に不備がある場合は、申請内容の修正を促すように警告文を自動で投稿 申請のステータスによって、SlackのAttachmentの色を変更 Devin による利用資格設定の自動化 PAMの利用資格の中に取得したい権限が存在しない場合、利用資格を修正する必要があります。 PAMの移行当初は取得できる権限が不足しており、利用者から多く依頼を受けていました。 その度にTerraformの定義を修正しレビューするのは大変です。 そこで、Devinを使って、Terraformの修正からPRの作成を自動でしてもらうようにしました。 Devin Playbook で利用資格を修正するPR作成作業を定型化しています。 利用者がSlack Workflowで追加してほしい権限を入力するとDevinが呼び出され自動でPRを作成します。 あとは、チームメンバーがPRをレビュー、マージして反映するだけです。 Devin による利用資格の変更PRの作成 まとめ 権限の最小化を徹底するために導入していたJIT Access Systemを、内製システムからGoogle Cloud PAMに移行しました。 PAMに移行したことで最小粒度の認可制御が可能になり、より安全にGoogle Cloud を運用できるようになりました。 また、AIエージェントの活用により運用の改善を効率良く実施できました。本当に便利なものですね。 みなさんがGoogle Cloud PAMを導入するときの参考になれば幸いです。 *1 : Terraformで管理

こんにちは、キャディで Quote というアプリケーションを開発している plant こと石田 ( @plant_ja ) です。 ハーネスエンジニアリングという言葉を目にする機会が増えてきましたね。「何をやるべきか」については OpenAI の Harness engineering: leveraging Codex in an agent-first world や逆瀬川さんの Claude Code / Codex ユーザーのための誰でもわかるHarness Engineeringベストプラクティス が非常に参考になります。 本記事では「何を」ではなく「どう始めるか」に焦点を当てています。Claude Code の場合だと Rules、Skills、Hooks、Subagents、さらには custom linter や pre-commit や pre-push、これらの構成要素を眺めているだけで「ちゃんとやろうとしたら大変そうだな」という気持ちになりますよね。 この記事では、そのハードルを下げるための1つのシンプルなアプローチを紹介します。 この記事のゴール ハーネス整備のハードル ルール整備によって変わったこと なぜうまくいったのか : 枠組みがあると更新のハードルが下がる 始め方 : 枠組みだけ先に作る プロンプト例 Rules 以外にも枠組みは作れる 終わりに この記事のゴール この記事のゴールは、ハーネスエンジニアリングの着手のハードルを下げることです。 「完璧なハーネスを最初から作り込まなきゃ」と構えるのではなく、「とりあえず枠組みを作って、そこからチームで育てていく」という発想を持って、気軽にハーネスの整備を始められるようになることが目標です。 ハーネス整備のハードル コーディングエージェントに実装させた結果、期待に満たないコードが生成されることがありますよね。 効率の悪さを感じながらも、その度に毎回「コードから自明なコードコメントは不要です」「 as unknown as のような危険な型キャストは使わないでください」という細かい指摘をすることになっていました。アーキテクチャ周りのドキュメントは充実していたのですが、実装の細部のガイドラインはまだまだ整備されていませんでした。 重要性は理解したものの、ハーネス整備にあたってのいくつかの心理的なハードルによって中々整備が進められていないという状況が数週間ほど続きました。 「そもそもハーネスエンジニアリングについての目線をチームで揃えないと」 「どういう形式でルールを整備するべきなんだろう、先にチームで議論しないと」 「ルールファイルを新たに追加したくなったけど、流石に実装 PR とは分けたほうがいいよな」 そんなことを考えつつ、ハーネスエンジニアリングについての目線をチームで揃えたり、custom linter を整備するなどの活動を進めたのですが、「やっぱり Rules ファイルの整備が手っ取り早く品質を向上させるためのアプローチだ」と考え、重い腰を上げて自分が開発しているアプリケーションのバックエンドの実装ルールを Claude Code の Rules ファイルとして整備することにしました。 ▶ 補足 : Claude Code の Rules とは Claude Code には CLAUDE.md というファイルにプロジェクトの指示を書く仕組みがありますが、指示が増えてくると1ファイルでは管理しづらくなります。 Rules は .claude/rules/ ディレクトリに Markdown ファイルを置くことで、指示をトピックごとに分割して管理できる仕組みです。例えば testing.md 、 api-design.md のようにファイルを分けられます。 さらに、YAML frontmatter で paths を指定すると、特定のファイルパスに一致するファイルを Claude が読んだときにだけルールが読み込まれる conditional rules として機能します。例えば paths: ["src/api/**/*.ts"] と指定すると、API 関連のファイルを扱うときだけそのルールが適用されます。 paths を指定しないルールはセッション開始時に常に読み込まれ、 CLAUDE.md と同じ扱いになります。 詳しくは 公式ドキュメント を参照してください。 Rules ファイルは、レイヤーを横断した汎用的な Rules (coding-style.md, testing.md) や、レイヤー毎の実装ルール (usecase.md, usecase_testing.md) に大別することとしました。 Rules を整備するために、既存の実装から実装パターンを推論して Rules ファイルを生成するスキルを作成しました。ファイルの生成自体はそこまで時間がかからずにできたのですが、実装方針がふわっとしている部分について意思決定を下したり、細かいニュアンスの修正など、想像以上にルールのレビューに時間がかかり、全てのレイヤーに対してのルールを作り切るまでに丸一日を費やしました。 しかし、ハーネスエンジニアリングの土台整備という観点だと、ここまでやる必要はなかったということに後に気づくことになります。 ルール整備によって変わったこと バックエンドの Rules ファイルが一通り整った上で、実装を進める中で「これもルールに盛り込みたいな〜」という点がいくつも出てきます。そこで、ルール更新用のスキル（ /update-coding-rule ）を作り、 /update-coding-rule コードから自明なコードコメントは不要です という指示を Claude Code に出すと、対応するルールファイルを探して追加・更新してくれるようにしました。実装の途中で出る細かい不満が、そのままチームで管理している品質基準へのフィードバックになるわけです。 PR レビューのコメント URL を渡しても同じことができるようにしました。 /update-coding-rule <PR のコメント URL> と指示するだけで、スキルが該当スレッドを取得して、PR レビューでの指摘をルール化してくれます。 このスキルを何回か使っていく中で、 「実装中の細かい不満をチームの品質基準に反映させる」という作業に対しての心理的なハードルがとても下がっている ことに気づきました。 ▶ 補足 : /update-coding-rule のスキル定義テンプレート 自分が使っているスキルをプロジェクト固有の部分を取り除いてテンプレート化したものです。 .claude/skills/update-coding-rule/SKILL.md として配置すれば、 /update-coding-rule で呼び出せます。 --- name: update-coding-rule description: フィードバックや PR レビューコメントからルールを一般化し、ルールドキュメントに反映する。 argument-hint: "[PR comment URL or feedback text]" --- # コーディングルール更新スキル フィードバックを一般化し、コーディングルールドキュメントに反映する。 ## フロー ### 1. フィードバックの収集 - PR コメント URL が渡された場合は GitHub API でスレッドを取得する - テキストが渡された場合はそのまま使う - 不明確な場合は AskUserQuestion で確認する ### 2. フィードバックの汎用化 具体的なフィードバックを、再利用可能なルールに変換する。 - 具体的な変数名・クラス名を抽象化する - 特定のコード修正指示から、背景にある原則を抽出する - GOOD / BAD のコード例を添える ### 3. 配置先の決定 ルールドキュメントのディレクトリ構成を確認し、どのファイルに追加すべきかを判断する。 既存ルールとの重複・矛盾がないかも確認する。 ### 4. ユーザーへの確認 AskUserQuestion で以下を提示し、確認を取る。 - 一般化したルールの内容 - 配置先ファイルとその理由 - 重複・矛盾の有無 ### 5. ルールファイルの更新 確認が取れたら、対象のルールドキュメントにルールを追記する。 なぜうまくいったのか : 枠組みがあると更新のハードルが下がる ここからが気づきです。ルールが育つようになった理由は、「充実したルールファイルを最初から用意した」からではなく、「ルールファイルをどこに・どんな形で置くか」という枠組みが決まっていたからです。 枠組みがあると、ハーネス整備に際してのハードルがグッと下がります。ハーネスの形式は既に決まっているので、その中身をリッチにしていくという営みは日常の開発の延長線上で容易に行うことができます。 この経験を経て、 重要なのはルール内容の充実度ではなく、誰でも更新しやすい状態になっていること だと気づきました。内容がスカスカでも、「これはここに追加すればいいんだ」という道筋が見えていることの方が大切なのだと。 始め方 : 枠組みだけ先に作る ここからが実践です。私は1日かけてルール全体をいきなり整備しましたが、そこまでやる必要はありませんでした。 枠組み（ほぼ空のルールファイル群）だけ先に作ってしまえば、始められます。 プロンプト例 プロジェクトのアーキテクチャをざっと分析してもらい、Rules ファイルの骨組みを作るプロンプトの例です。 自分がメインに利用しているのが Claude Code なので、Claude Code に特化した内容になっています。 このプロジェクトのアーキテクチャを分析して、Rules ファイルの骨組みを作ってください。 ## ルールドキュメントの種類 ルールドキュメントは下記の 2 種類に大別します。 ### 1. 汎用ルール レイヤーを横断する共通方針です。ユーザーにどのような汎用ルールを作成したいかを インタビューした上で、必要なものを作成してください。 例 : `coding-style.md`, `testing.md`, `error-handling.md`, `observability.md` ### 2. レイヤー別ルール レイヤーごとにサブディレクトリを作り、実装ルールとテストルールを分離します。 例 : `usecase/usecase.md`, `usecase/usecase_testing.md` ## ルールドキュメントの要件 - 各ルールドキュメントには概要のセクションを用意して、ルール自体の説明を書く - coding-style.md の例 : XXXプロジェクトのコーディングスタイルに関する横断ルール - usecase/usecase_testing.md の例 : Usecase 固有のテストルール。共通のテストルールは testing.md を参照。本ドキュメントの規約が testing.md と競合する場合、本ドキュメントを優先する。 - 既存のコードから明らかに読み取れるルールがあれば、セクションを追加して1~2個ほど簡潔に記入しても構わない ## .claude/rules/ のインデックスファイル ルールドキュメント本体の置き場所はユーザーにインタビューして決めてください。 `.claude/rules/` 配下のファイルはインデックスとして扱い、ルール本体への参照だけを記載します。ディレクトリ構成はルール本体のディレクトリ構造と一致させるようにします。 frontmatter の `paths` で対象ファイルパスを指定し、本文にはルールドキュメントへのパスを書きます。 以下は Usecase のテストルールのインデックスファイルの例です。 --- paths: - "src/usecase/**/*.spec.ts" --- # Usecase テストルール Usecase のテストを新規作成・修正する場合、計画開始前もしくは作業開始前に以下のルールファイルを読み込むこと: <ルールドキュメントへのパス> このプロンプトを Claude Code に渡すと、「ここに何を置くか」という地図ができます。 ▶ 補足 : なぜ .claude/rules/ をインデックスとして扱うのか Claude Code の Rules は paths を指定することで conditional rules として設定できます。該当パスのファイルをセッション中に初めて Read したタイミングでルールが読み込まれる仕組みです。 ルールの内容がリッチになってトークン数が増えてくると、コンテキストウィンドウを圧迫したり、attention が分散して本当に必要なタイミングで必要なルールが考慮されにくくなるという問題が起きやすくなります。 これを避けるために、 .claude/rules/ 配下のファイルはインデックス（参照先のパスだけを記載した軽量なファイル）として扱い、ルール本体は別の場所に置くという構成を採用しています。こうすることで、conditional rules として読み込まれるトークン数を最小限に抑えつつ、エージェントが必要に応じてルール本体を読みに行く形にできます。 Rules 以外にも枠組みは作れる 今回は Rules の整備を例に挙げましたが、同じ発想は Rules ファイル以外でも使えると考えています。例えば Skills であれば、API の stub を生成するスキル（ /create-api-stub ）を最低限の機能で作っておくだけで、使う中で「リクエストパラメーターのバリデーションもこの時点で入れるようにしよう」などといったフィードバックが自然と集まるようになります。Hooks であれば、Stop hooks や PostToolUse hooks などの各タイミングで走らせるための専用のスクリプト (例: stop-hook-script.js) を用意しておき、そこを少しずつ充実させていくなどのアプローチが取れるかもしれません。 枠組みと責務が明確だと、更新・拡張のハードルが下がる。 Rules に限らず、この原則は共通しているはずです。 終わりに ハーネスエンジニアリングは、完璧な仕組みを設計してからスタートするものではないと思っています。見出しだけのルールファイルでも、空っぽのスキルでも、「ここに足していける」という場所があるだけで、チームの誰かが気づいたことを反映できるようになります。 開発とハーネス整備を区別せず、同じタスクの中で完結させる。この感覚が根づくと、ハーネスは勝手に育っていくのではないでしょうか。 この記事で取り上げたような課題感をお持ちの方は、ぜひ枠組みを作るところからスタートしてみませんか？ また、キャディでは一緒に働く仲間を大募集中なので、興味があれば下記もぜひご覧ください。 speakerdeck.com

はじめに 何が辛かったのか 毎回詳細なプロンプトを書くのが辛い AIエージェントのタスク完了まで面倒を見るのが辛い これらを並列で実行しているのが辛い 解決方針 詳細な設計ドキュメントの作り込み Usecase Design Doc 細かい実装指示・計画・実行をAIエージェントに委譲 タスクの分割方針 AIエージェントへの実装委譲 AIのお世話からの解放 - 得られた成果 開発速度の向上 PRレビュー自体の認知負荷の軽減 現在直面している課題 設計書の細かい誤りの増幅 設計とPRレビューのボトルネック化 まとめ はじめに こんにちは。CADDi Quoteのサーバーサイドの開発を担当しています、majimacchoです。私たちのチームでは全員がAIエージェントを活用して実装しPR作成まで行なっています。 私自身を含め、全く自分でコードを書かなくなったメンバーもいます。AIエージェントを使ってから個人のアウトプットは大きく増えましたが、その分 AIのマネジメント(お世話)の負荷 が高まっていました。 今回紹介するUsecase Design Docと呼ばれるドキュメントと関連する施策を通して、このAIのお世話の負荷を軽減しました。またそれに付随して1日にマージできるPRの数は2倍になっています。 この記事では、AIエージェントを利用した開発で増大するAIのお世話の負荷をどう軽減したかを、具体的な開発プロセスと合わせてお伝えします。 何が辛かったのか 私は大きく以下の3つのことが辛いと感じていました。 毎回詳細なプロンプトを書くのが辛い AIエージェントのタスク完了まで面倒を見るのが辛い これらを並列で実行しているのが辛い 毎回詳細なプロンプトを書くのが辛い AIが実装を行う際に「OOを実装して」のような曖昧な指示では期待通りのコードを作成してくれません。1つのPRを作成するのに、かなり多くの説明をしなければいけないことに負担を感じていました。AIしか読まない詳細な文書を書くことに虚無感すら覚えていました。様々なツールやスキルによって、ある程度個々の負担は軽減できますが、それでもAIのための指示を、その都度、正確にしなければいけませんでした。 AIエージェントのタスク完了まで面倒を見るのが辛い 最近のAIエージェントは十分賢くなったので、全ての挙動を見張る必要はなくなりました。 しかし、特にClaude Codeを利用している場合は、プランを確認したり、ツールの利用を許可したりするところで、まだ人間の操作を必要としています。 PR作成後もそのまま受け入れられる品質の時は良いですが、修正が必要な場合、何度もやり取りが発生したり、場合によってはセッションをクリアする必要があります。 これらを並列で実行しているのが辛い 上記の問題は、直列で作業している時には大きくなかったのですが、並列で仕事をするようになってから顕著になってきました。 特に、 1人で同時に5つ以上 のタスクをAIエージェントと実装するようになってからは、認知負荷が顕著に上がってしまいました。 AIコーディング以前は並列で作業することが間違っているという考え方が主流だったと思います。しかし、AIエージェントを待っている間に別のエージェントを動かさないと機会損失しているような感覚があり、ほとんどの時間に、AIを並列稼働させています。 ローカルでGit Worktreeを管理する必要も出てきたり、開発サーバーのポートが競合することもあります。手動でmainブランチをマージするのを忘れて、何度もコンフリクトを起こしました。 コンテキストスイッチも大きくなり一時期は並列数を3つまでに制限することもありました。 解決方針 上述の課題を以下の方針で解決しました。 詳細な設計ドキュメントの作り込み 細かい実装指示・計画・実行をAIエージェントに委譲 詳細な設計ドキュメントの作り込み 今回重要だったことは、細かい指示を出さなくても、AIエージェントが質の高いアウトプットを出せることです。 試行錯誤する中で、Usecase Design Docという形でより細かい設計内容をまとめることで、AIエージェントのアウトプットの質が高められることがわかりました。 Usecase Design Doc 以前はユースケースレベルの設計はPRのDescriptionやホワイトボードツールに散在しており、各開発者の暗黙知に依存していました。これを明文化することで、AIにとっての実装のエントリーポイントになると同時に、レビュー時の照合基準としても機能しています。 このドキュメントには、ユースケースシナリオに閉じた設計を記載します。具体的には以下の内容を含んでいます。 サマリー（アクター・操作対象・操作内容の定義） 関連テーブルのCRUD表 シーケンス図（トランザクション境界を含む） 主要なドメインエンティティのインターフェース（型定義・ファクトリメソッド） 関連するAPIインターフェース（API仕様書から抜粋） 既存コードへの変更箇所（レイヤーごと） 実装状況チェックリスト（集約単位・レイヤー単位） 以下は架空のユースケースを例にしたUsecase Design Docのサンプルです。実際のプロダクトのものではありませんが、記述の粒度やフォーマットは実際に使用しているものと同等です。ただし、サンプル内のユースケース・設計・コーディング規約は実際のものとは異なります。 # EX-a1: ユーザーはお気に入り商品をブックマークする ## サマリー - ログインユーザーが商品に対して、ブックマーク（お気に入り登録）を行う ## 関連のテーブル | テーブル | 操作 | 操作内容 | | :--- | :---: | :--- | | Product | R | ブックマーク対象の商品が存在することを確認する | | Bookmark | CR | ブックマークの存在確認（R）、新規作成（C） | | BookmarkCount | U | 商品のブックマーク数を +1 更新する | ## シーケンス図 ```mermaid sequenceDiagram autonumber actor User as ログインユーザー participant API as Product API<br/>[REST] participant DB as App DB<br/>[PostgreSQL] User->>API: POST /products/{productId}/bookmarks API->>DB: 商品の存在確認 alt 商品が存在しない API-->>User: 404 Not Found else 商品が存在する API->>DB: 既存ブックマークの確認 alt 既にブックマーク済み API-->>User: 409 Conflict else 未ブックマーク rect rgba(100, 150, 255, 0.15) Note over API,DB: トランザクション API->>DB: Bookmarkを保存 API->>DB: BookmarkCountを+1更新 end API-->>User: 201 Created end end ``` ## 主要なドメインエンティティのインターフェース > 実際のドキュメントではここにエンティティの型定義とファクトリメソッドを記載します。 > 例: ` type Bookmark = Readonly<{ id: BookmarkId; userId: UserId; productId: ProductId; ... }> ` > 例: ` const Bookmark = { create: (...) => Bookmark, ... } ` ## APIインターフェース > 実際のドキュメントではここにAPIのパスパラメータ・リクエストボディ・レスポンスの定義をテーブル形式で記載します。 > 例: パスパラメータ ` productId: string ` 、レスポンス ` 201 Created / 404 Not Found / 409 Conflict ` ## 既存コードの変更 > 実際のドキュメントではここにドメイン・ユースケース・インフラストラクチャ・プレゼンテーション等のレイヤーごとに、変更対象のファイルパスと変更内容をテーブル形式で記載します。 ## 実装状況 - [ ] 同期処理 - [ ] Bookmark 集約 - [ ] ドメインの実装 - [ ] ユースケースの実装 - [ ] プレゼンテーションの実装 細かい実装指示・計画・実行をAIエージェントに委譲 今までの開発ではAIエージェントに実装させる中でも、以下のようなタスクのために、AIエージェントとローカル環境に注意を向けなければいけませんでした。 最初のプロンプトの入力 コンテキストがいっぱいになった時のセッションマネジメント Toolの利用の許可 今回は、これらに注意を払わずに、設計とPRレビューに集中するプロセスを構築しました。 Usecase Design Docの内容を元にユースケースシナリオごとに実装タスクを計画します。 タスクの分割方針 ユースケース全てを1つのPRで実装するには大きすぎるため、基本的には以下の軸で分割します。 レイヤー単位（Presentation / Domain / Application） DDDの集約単位 同期・非同期の処理単位 この分割の基準は先ほどのUsecase Design Docのテンプレートに含まれています。 各PRは200〜300行の変更に収まることを目安にしています。この分割により、PR1件あたりの情報量が制限されます。さらに、レビュアーが把握すべき知識の範囲もレイヤーや集約の境界内に限定されます。 AIエージェントへの実装委譲 タスク分割が完了したら、以下の流れでAIエージェントに実装を委譲します。 Usecase Design Docの実装状況の欄のうち、未実装の項目の一番上を実施タスクとする Devin Searchで関連コード・ドキュメントを収集 : タスクを指定して、Usecase Design Docと関連する既存コードをDevinに読み込ませる DevinでPR作成まで実行 : タスク定義に基づいてDevinが実装し、PRを作成する CIのDevin Reviewで自動レビュー : 作成されたPRに対してCI上でDevinによる自動レビューが走る 設計ドキュメントが十分に詳細化されていれば、この一連の流れに人間が介入する必要はありません。お昼前にタスクを投入し、出来上がったPRを午後にレビューするという非同期な作業サイクルが成立します。 AIのお世話からの解放 - 得られた成果 従来のような並列でAIのタスクとセッションを管理しなければいけないような環境から脱却し、心には平穏が訪れました。 心理的、認知的に楽になっただけではなく、業務上も以下の成果が得られました。 開発速度の向上 従来のAIを活用した開発と比較して 1日にマージされるPRの数が2倍になっています。 これはAIエージェントが人間を待たずに作業ができるようになったことと、アウトプットの質が上がって手戻りが減ったことによるものです。 また、今までAIエージェントへのプロンプトやセッション管理を通じた直接的なマネジメントから、AIエージェントの環境整備を行なって、セッション横断で効果のある施作に時間が割けている事もその要因の1つです。 さらに、並列数の上限も特になくなり、その日のPRレビューに割ける時間から逆算して実装タスクの数を決めるようになりました。 PRレビュー自体の認知負荷の軽減 詳細な設計ドキュメントがPRレビュー時にあることで、PRの内容をすぐに理解できるようになりました。今まではなんとなく頭にあった情報を思い出してレビューしていました。今は詳細な設計ドキュメントと照らし合わせながらレビューしているのでレビュー時のコンテキストスイッチによる負荷も小さくなっていると感じています。 現在直面している課題 設計書の細かい誤りの増幅 今回、主要なインターフェースの設計もAIに書かせていましたが、軽微な間違いを含んだまま実装フェーズに進み、そのままPR作成まで行われるケースがありました。一見些細なインターフェースの誤りでも、実装を通じて増幅され、結果として大きなズレにつながります。開発者が実装に伴走していれば、PR作成前の段階で気づけていたはずですが、今回のプロセスではPR作成後に初めて問題が表面化しました。設計ドキュメント自体のレビュー精度を高めるか、実装の途中段階でフィードバックを得る仕組みを整えることが今後の課題です。 設計とPRレビューのボトルネック化 よく言われていることではありますが、実装速度が上がったことで、その前後の設計とPRレビューの速度が開発スピード全体を決めるようになりました。 特に設計は、AIに手放しで任せるのは難しい領域が大きく、まだまだ時間がかかってしまうところです。 PRレビューについてはハーネスエンジニアリング *1 によって不要になるという論調もありますが、本番環境で、お客様が利用しているサービスにPRレビューなしでマージするには課題が多いのも現状です。 まとめ AIエージェントに指示を出す前の段階で実装内容が自明になることで、AIエージェントの管理工数を削減し、開発者の認知負荷を軽減することができました。 この取り組みを通して確認できたことは、実装時にAIエージェントに指示内容を考えるよりも、設計時点で詳細な実装までイメージできるようなドキュメントを作成した方が効率が良いことです。 この設計ドキュメントを、どれだけ正確に無駄なく作れるかということが開発速度と品質を左右します。 AIエージェント自体をどれだけうまく活用するかということも現時点では重要ですが、それらはツール側の成熟によって自然と解決していきます。一方で設計はまだまだ人間が考えるべきところが多く残されていると思います。 もしチームで試すなら、最小限の構成としてUsecase Design Docの整備から始めることをおすすめします。ユースケースごとにサマリー・シーケンス図・実装状況チェックリストをまとめたドキュメントを1つ作り、それをコードベースの特徴に合わせて分割した上でAIエージェントに渡して実装させてみてください。設計の曖昧さがどこにあるかがすぐにわかり、改善サイクルが回り始めます。 このプロジェクトは、まだ進行中で試行錯誤しているところも多分にあります。プロジェクト完了後にふりかえり記事を出してその時に答え合わせをしようと思っています。 *1 : My AI Adoption Journey - Mitchell Hashimoto , Harness Engineering - OpenAI

こんにちは、ReliabilityグループでQAエンジニアをやっているyokota( @katawara )です。昨年の10月に入社しました。 入社直後のバタバタも落ち着いてきて、ようやく本格的にClaude Codeを使い始めたのですが、いろいろと試行錯誤を重ねてみているので、その中の活動のひとつをご紹介しようかと思います。 目次 目次 背景 Claude Codeのサブエージェント機能 MAGIシステムとは？ スリーアミーゴスとは？ サブエージェント x MAGIシステム = スリーアミーゴス 実際にやってみた 神田（PdM人格） 袴田（エンジニア人格） 秋山（QA人格） 設計のポイント おためしで動かしてみた サブエージェントなしとの比較 やってみてわかったこと 今後やりたいこと 背景 Claude Codeを活用するにあたり、大事になってくるのはコンテキストマネジメントかなと思っています。 *1 ところが、コンテキストマネジメントを意識しながらQAのお仕事をやらせようとすると、なかなか難しいことがわかってきます。ビジネス的な背景を理解しながら、技術的な制約も把握しつつ、仕様の裏や隙間も考える、という感じで、 一度にたくさんのことを把握しながら深く考えなければいけません 。 コードと複数サービスにまたがるドキュメント（キャディの場合はConfluenceやMiro、Figma、Google Spreadsheetなど）をMCPやCLIで読ませつつ、それらの分析をひとつのプロンプトで全部やらせようとすると、どうしてもアウトプットが薄くなったり、ある観点が抜け落ちたりしがちです。 そこで今回目をつけたのがサブエージェントという手段です。 Claude Codeのサブエージェント機能 Claude Codeには「サブエージェント」という仕組みがあります。 .claude/agents/ 配下にマークダウンファイルを置くだけで、独自のペルソナを持ったエージェントが定義できます。定義の仕方もシンプルで、冒頭にメタ情報を書き、続けてそのエージェントへの指示を書くだけです。 会話の中で @エージェント名 という形で呼び出せるほか、エージェント側からさらに別のエージェントに委任するといったこともできます。 また、サブエージェントを利用すれば、サブエージェントが使うコンテキストはメインセッションのものとは別になるので、コンテキスト消費の節約にもなります。 この発想が、自分に2つのものを連想させました。それがタイトルの 「MAGIシステム」 と 「スリーアミーゴス」 です。 MAGIシステムとは？ アニメ「新世紀エヴァンゲリオン」に登場する、3台のスーパーコンピュータで構成された意思決定システムのことです。 3台はそれぞれ「メルキオール」「バルタザール」「カスパー」という名前がついており、開発者である赤木ナオコ博士の「科学者」「母親」「女性」という3つの人格が設計に反映されています。3台がそれぞれ独立して判断を下し、多数決で結論を出す、という仕組みです。 スリーアミーゴスとは？ スリーアミーゴスというのは、アジャイル開発の文脈で聞かれることのある言葉です。PdM・エンジニア・QAの三者が同席して仕様について話し合う、というプラクティスのことを指します。 三者が揃うことで、ビジネス的な視点、技術的な実現方法の視点、品質保証の視点が交わり、仕様の抜け漏れや曖昧さを早期に発見できます。 サブエージェント x MAGIシステム = スリーアミーゴス ここまで、MAGIシステムとスリーアミーゴスには共通点があります。 いずれも3つの人格がそれぞれ独立して考えるという点です。 つまり、 メルキオール、バルタザール、カスパーの代わりに、PdM、エンジニア、QAの三者が動く世界が再現できれば、コンテキストマネジメントを適切にこなしつつ、通常のプロンプトを動かすよりも精度が高いアウトプットが出てくるのではないか 、という仮説を立てました。 実際にやってみた ということで、この発想をもとに、3人の人格を作ってみました。 名前がないと呼ぶときに不便かなということで、名前もつけています。なぜこの名前なのかわかった方はたぶん同世代だと思います。笑 神田（PdM人格） ビジネス価値・ユーザー価値の観点で要件を整理します。ユーザーが迷わず目的を達成できるかどうか、価値が毀損される可能性はないか、といったトピックに特に関心を払います。 袴田（エンジニア人格） 技術的な実現方法・境界値・制約条件を分析します。アプリケーションコードの実装リスクや、インフラの制約から来る潜在的なリスクに特に関心を払います。 秋山（QA人格） テスト観点・エッジケース・仕様の裏や隙間といったものに注目します。正常な動作だけでなく、意図と違う行動をされたときの挙動や、インシデントにつながりかねないリスクに特に関心を払います。 以下は一例ですが、たとえば、こんな感じで書いています。 おおまかな下書きはClaudeに書いてもらっています 設計のポイント こだわったのは、エージェントの定義を「誰が（ペルソナ）」と「何をするか（ワークフロー）」に分けた点です。 エージェント自体はあくまで汎用的なペルソナとして定義し、具体的な作業はプロンプト側で指定します。こうすることで、同じエージェントをいろんな場面で使い回しができるようになります。 また、それぞれのエージェントが参照すべきドキュメントについては、あえて変えるようにしています。同じものを全員が参照できてしまうと、アウトプットにバリエーションが出ないかなというところで、分散させるという選択をしています。 誰が何を見られるなどを考えた雑な図 最終的には、それぞれ一時アウトプットを出すような形にしていて、メインセッションでそれらを統合して全体としてのアウトプットを出すことにしています。 おためしで動かしてみた 試しに、Playwrightの公式サンプルとして有名な TodoMVC を題材に、3人に同じアプリを別々の視点で分析させてみました。 神田さん（PdM人格） は、ユーザーストーリーやハッピーパス・エッジケースといった表現で整理してくれました。テストすべきものとして、実際の操作でありそうなパターンや、見た目の挙動みたいなところにフォーカスが当たっています。 受け入れ基準を出してくるあたりPdMっぽい 袴田さん（エンジニア人格） は、データ永続化やバリデーションといった観点で整理してくれました。テストすべきものとして、ページリロードや状態遷移といった、技術的に何か変化がありそうなところにフォーカスが当たっています。 実装で気を遣いそうな部分を見ている雰囲気 秋山さん（QA人格） は、ちょっと意地悪な視点からのシナリオを出してくれました。テストすべきものとして、異常値や境界値、アクセシビリティ、非機能要件といったところにフォーカスが当たっています。 テスト観点の提示数は一番多かった サブエージェントなしとの比較 サブエージェントなしでも同じことをしてみました。 テストケースだけで言えば、サブエージェントなしで31件、サブエージェントありで43件となりました。 左が素の状態、右がサブエージェント利用の状態です 数だけが重要というわけではないですが、見比べてみると、ハッピーパス外のことに意識を払っていたり、技術的な裏側まで見ていたりする部分があり、非常に興味深いです。 やってみてわかったこと 3人がそれぞれ独立して分析することで、アウトプットの形式はだいぶばらつきますが、全部をまとめると、視点のバランスがとれながらも、ちょっと突っ込んだ調査ができたアウトプットになりそうです。「テスト」という言葉でひとまとめにしていた作業が、PdMとして考えること・エンジニアとして考えること・QAとして考えることとして分解されることで、AIとして動きやすくなっているのかもしれません。 また、冒頭話題にしていたコンテキスト消費についても、この例では25％程度に抑えられており、実運用に投入して様子が見られそうという雰囲気があります。 今後やりたいこと 今後は、発生頻度が比較的高めの業務でどこまでやれるかから見ていこうと思っています。 幸いにして、キャディはいろんな意思決定をドキュメントに残す文化があるので、インプットに使えるものは多くあります。 最終的には、テスト観点のたたきを出してみたり、仕様書を取りまとめてみたりなど、いろんな業務に適用できるといいなと思います。 この記事がどなたかの参考になれば幸いです。 現場からは以上です！ *1 : 自社の記事にはなりますが、 こちらの記事 は自分もすごく勉強になりました

こんにちは。キャディ株式会社の Analysis Platform Group でソフトウェアエンジニアを務めている廣岡です。 業務としては、キャディの様々なサービスの裏側で稼働する機械学習解析のインフラやバックエンドの開発、アプリケーションとの橋渡しなどに取り組んでいます。最近では下記記事で紹介したようなプロジェクトに取り組んでいます。 zenn.dev 今回は私たちのチームで作り、開発業務の中で利用している Claude Skills について紹介します。 TL;DR Claude Skills を使って ML 開発における定型作業を効率化した 推論サーバー構成やログ調査、インフラ構築など 5 つのスキルを整備した エンジニアリングバックグラウンドが異なるチームで、開発効率が大きく向上した 背景 キャディの ML システムでは図面解析のための機械学習モデルを多数開発・運用しています。Analysis Platform チームでは、機械学習エンジニアと連携して ML モデルのデプロイ、運用まで一貫してサポートしていますが、いくつかの課題がありました。 1. 定型作業の属人化 「本番環境のエラーログを調査したい」「新しいモデルを追加したい」といった作業には、プロジェクト固有の知識が必要です。Kubernetes の namespace は何か、サンプルリクエストにはどのデータを使って良いのか、といった情報は README や他のドキュメントに散在しており、新メンバーのキャッチアップや作業完了に時間がかかっていました。 2. プラットフォームの複雑性 私たちは LitServe（ML 推論サーバー）、Pub/Sub（非同期ジョブキュー）、GKE など複数の技術を組み合わせて ML 基盤を構築しています。効果的にデプロイや調査を行う上では、それぞれの技術やシステムの仕様を把握しておく必要がありました。 3. コンテキストスイッチのコスト 「ツールの仕様や使い方を理解する」→「作業を実施する」→「結果を確認する」という業務フローの中で、最初の「ツールの仕様や使い方を理解する」に多くの時間や労力を費やしていると感じていました。 キャディのエンジニア組織では Claude Code を広く利用しており、Claude Skills を導入することでこれらの課題に対処できないかと考えました。 caddi.tech Claude Skills とは Claude Skills は、Claude Code に対してプロジェクト固有の知識を与える仕組みです。 .claude/skills/ ディレクトリに SKILL.md ファイルを配置することで、Claude がその知識を参照しながら作業を行います。これによって開発・運用時の仕様への準拠や、各種ツールの使い方を自然言語ベースで記述でき、業務の生産性や品質を向上できると期待しました。 スキルは YAML と Markdown で記述します。詳細は 公式ドキュメント や Anthropic のスキルリポジトリ を参照してください。 整備したスキル一覧 前述の背景を踏まえて、ここでは 5 つのスキルを紹介します。 1. add-litserve-model 新しい LitServe サーバーの実装を追加するスキルです。 LitServe は Lightning AI が開発した推論サーバーフレームワークで、私たちは GPU 上の ML ウェブサーバーを構築する上で採用しています。 LitServe にはマルチプロセスでの動作や動的バッチ推論など、ML サーバーを構成する上で便利な機能が多く搭載されています。ボイラープレートコードの生成や主要な推奨設定をスキルとして整備することで、推論サーバーの実装作業を効率化しています。 .claude/skills/add-litserve-model/ ├── SKILL.md # 生成手順、要件定義 ├── ADDITIONAL_SETUP.md # CI/CD、K8s マニフェストのセットアップ └── examples/ ├── api.py # LitServe API のテンプレート ├── models.py # Pydantic モデルのテンプレート ├── main.py # サーバーエントリポイント ├── Dockerfile # GPU 対応 Dockerfile └── pyproject.toml # 依存関係定義 スキルの中では例えば下記のような構成を記載しています。これらを記載しておくことで、実装時の設定や構成の漏れを減らすことができます。 リクエスト・レスポンスのモデル、画像のリクエスト方法 動的バッチング（batch/unbatch メソッド）の実装パターン GPU 環境での Dockerfile CI/CD（GitHub Actions）や Kubernetes マニフェストのセットアップガイド 使用例: > /add-litserve-model sample_ml モデル名を指定すると、以下のようなディレクトリ構造が生成されます。 src/caddi_ai_models/sample_ml/ ├── src/ │ ├── __init__.py │ ├── models.py # Pydantic request/response │ ├── api.py # LitServe API（動的バッチング対応） │ └── main.py # Server entry point ├── tests/ │ └── test_api.py ├── Dockerfile # GPU 対応イメージ └── pyproject.toml 動的バッチングの実装パターンや GPU 推論のためのライブラリ設定など、つまづきやすいポイントがスキルに含まれているため、新しいモデルの追加がスムーズに行えます。 2. sample-request ML API へのサンプルリクエストを送信するスキルです。各環境での API 動作確認に使用します。 .claude/skills/ml-sample-request/ └── SKILL.md # エンドポイント URL、認証方法、リクエスト例 キャディの ML API は図面（画像）解析リクエストを送ることが多くあります。画像データはリクエストボディを構築するのが手間だったり、リクエストのために使って良いサンプルデータがどこに書かれているかわかりづらいこともあったため、スキルとして明示的にしておくことで検証が容易になっています。 環境ごとのエンドポイント URL や認証方法をスキルに含めることで、「この環境の〇〇サービスににテストリクエストを送りたいんだけど、コマンドを教えて」というやりとりに対応できます。 私たちの開発環境では dev 環境にはエンジニアから直接リクエストを送れる一方で、stg, prod 環境のサービスはシステムの安全のために踏み台からアクセスするという運用になっています。これに対応して、dev 環境向けには Claude Code から直接リクエストを送り、stg, prod 環境向けにはリクエストに必要なコマンドを提示するようにしています。 3. cloud-logging GKE 上のサービスのログを Cloud Logging から取得して調査するスキルです。Claude Code から gcloud logging コマンドを実行することでログを調査します。このスキルは地味ながら重宝しており、特に作って良かったと感じています。 個人的に Google Cloud の Cloud Logging のクエリは書き方にやや癖があり、コンソールからクエリを実行するのが億劫に感じていました。このスキルのおかげで、クエリの書き方を調べずに済み、エラーやパフォーマンスなど迅速なログ調査が可能になっています。 .claude/skills/cloud-logging/ ├── SKILL.md # 環境・サービス情報、基本コマンド └── examples/ ├── error-logs.md # エラーログ検索のサンプル ├── success-rate.md # 成功率計算のサンプル ├── performance.md # パフォーマンス分析のサンプル └── aggregation.md # 集計クエリのサンプル スキルには、Claude Code が適切にログを調査・分析できるように以下のような情報を盛り込んでいます。 環境（dev/stg/prod）ごとのプロジェクト ID サービスごとの namespace、ワークロード名の対応表 よく使う集計のサンプルクエリ コンテキスト効率化テクニック（jq によるフィールド抽出など） SKILL.md の抜粋: ## 環境とプロジェクトID | 環境 | プロジェクトID | |-----|---------------| | dev | caddi-ml-dev | | stg | caddi-ml-stg | | prod | caddi-ml-prod | ## 対象サービス一覧 | サービス | Namespace | Container名 | |---------|-----------|-------------| | caddi-ml-1 | caddi-ml | caddi-ml-1 | | caddi-ml-2 | caddi-ml | caddi-ml-2 | 使用例: Claude Skills はユーザーが直接実行できるほか、ユーザーとのやり取りの中で必要なシーンで自動的にトリガーしてもらうこともできます。ログスキルの場合は、例えば下記のようなプロンプトについても、ログスキルが反応してトリガーできています。 > prod 環境の caddi-ml-1 サービスで今日の夕方くらいにエラーが増えてるんだけど、エラーの種類と件数を整理して Claude がプロジェクト ID やフィルタ条件を適切に設定し、以下のようなコマンドを実行してログを取得・分析してくれます。 gcloud logging read \ 'resource.type="k8s_container" AND resource.labels.namespace_name="caddi-ml" AND severity>=ERROR' \ --project=caddi-ml-prod \ --limit=50 \ --format="json" Claude Code は jq などのコマンドの扱いもうまいため、JSON 形式で出力することでさまざまな加工や集計も可能になります。 4. async-job-analysis 非同期ジョブの投入と処理をまたいだログ分析スキルです。 キャディの ML システムでは、スループットが要求されるユースケース向けに非同期ジョブ型の解析も実行しています。非同期ジョブの集計ではサービスを跨いだ id join やリトライの考慮など、比較的複雑なシステム仕様を踏まえる必要があるため、個別のスキルとして定義することで必要に応じて呼び出すことができます。 内部では前述の cloud-logging スキルを使っており、より高度なユースケースに対応する形となっています。 .claude/skills/async-job-analysis/ ├── SKILL.md # ジョブフロー、ログイベント定義 └── examples/ └── success-rate.md # 成功率計算のサンプル スキルには以下のような内容を記載しています。 ジョブフローの概要（投入→Pub/Sub→処理→通知） 各イベントのログパターン 成功率計算、リクエスト→処理完了のリードタイム計測などのサンプルクエリ SKILL.md の抜粋: 非同期ジョブにおける各種イベントを整理しておくことで、Claude が柔軟に集計を実行してくれます。 ## ログイベント | イベント | Container | Message Pattern | Key Fields | |---------|-----------|-----------------|------------| | 投入成功 | job-proxy | ` Job submitted successfully ` | ` job_id ` , ` model_name ` | | ステータス通知 | job-runner | ` Published job status message ` | ` job_id ` , ` job_status ` | | 処理成功 | job-runner | ` Job processing completed successfully ` | ` job_id ` | | 処理失敗 | job-runner | ` Job {job_id} failed: {error} ` | ` job_id ` | 5. production-ready-k8s-deployment 社内標準に沿った Kubernetes Deployment のマニフェストを生成するスキルです。 キャディ社内では Production Readiness Checklist (PRCL) という形で、プロダクション環境でアプリケーションを安全に展開する上で重要な設定や要件をリスト化、チェックしています。リストの内容は多岐に渡りますが、例えば K8s マニフェストの設定項目も含まれます。 キャディではほとんどのアプリケーションが k8s クラスタ上に展開されています。K8s は柔軟な定義ができる一方でさまざまな設定項目があり、エンジニアが全てを熟知して設定するのは大変になり得ます。 このスキルでは、PRCL で定義されている K8s Deployment の項目と実際のマニフェストの定義方法を記載することで、認知負荷を少なくアプリケーションのマニフェストを構成できるようになります。 .claude/skills/production-ready-k8s-deployment/ ├── SKILL.md # PRCL 項目と対応設定、生成手順 ├── template.yaml # Deployment テンプレート └── examples.md # 実際のデプロイ例 具体的には下記のような内容を盛り込むことで、必要な設定がカバーされたマニフェストを簡単に定義することができます。 リソース制限、Probe、Graceful shutdown の適切な設定 Istio サイドカー（サービスメッシュ）や Datadog と統合するための設定 実際のデプロイ例の参照 SKILL.md の抜粋: ### Deployment Items Covered by This Template | PRCL ID | Item | Template Setting | |---------|------|------------------| | PRCL-01 | CPU req/limit | ` resources.requests.cpu ` , ` resources.limits.cpu ` | | PRCL-02 | Memory req/limit | ` resources.requests.memory ` , ` resources.limits.memory ` | | PRCL-03 | Graceful shutdown | ` terminationGracePeriodSeconds ` | | PRCL-04 | Liveness Probe | ` livenessProbe ` | |... 使用例: > /production-ready-k8s-deployment caddi-ml-server Claude がユーザーにデプロイ名、コンテナイメージ、ポート番号などを質問し、チェックリストに準拠したワークロードを構成できます。こちらは今は試験的に deployment でだけスキルを定義していますが、PRCL では他にスケーリングや可用性に関する項目があるため、将来的にはさらに k8s の他のリソース設定をカバーすることも有用だと考えています。 スキルを作る際の工夫 これらのスキルを作ってみて、感じたことを記載しておきます。 コンテキストウィンドウの節約 Claude Code はコンテキストウィンドウを消費するため、スキルの内容が長すぎると本来の作業に使えるトークンが減ってしまうため、以下の工夫をしました。 本体（SKILL.md）は簡潔に保ち、詳細は examples/ ディレクトリに分割 Claude が必要に応じて examples を参照する設計 .claude/skills/cloud-logging/ ├── SKILL.md # 基本情報のみ └── examples/ ├── error-logs.md # エラーログ検索のサンプル ├── success-rate.md # 成功率計算のサンプル └── performance.md # パフォーマンス分析のサンプル 開発者向けドキュメントとの統合 元々いくつかのスキルでは、必要な記載を全て .claude/skills 以下に配置していました。一方で、例えばサンプルリクエストの送信方法やログにおけるサービス名などは、アプリケーション側の README.md などにも書かれており、記載が重複している箇所がありました。 スキルと独立したアプリケーションの仕様やマニュアルは開発者向けドキュメント（例えば docs/ ディレクトリなど）として配置し、スキルからはそのドキュメントを参照する形を試しています。これによって開発者からもコーディングエージェントからも同じドキュメントが有用になり、ドキュメントのメンテナンスも一元化できると考えています。 効果と今後やりたいこと Claude Skills の導入によって、ログ調査などの運用オペレーションや、ML 推論サーバーの標準的な構成・開発など、さまざまなシーンで属人化解消、作業効率化の恩恵が得られています。 以下は今後さらにコーディングエージェントを使って実現してみたい内容です。 今後やりたいこと①：負荷試験レポート自動作成 やってみたい内容の一つとして、 負荷試験レポート作成の自動化 を考えています。 負荷試験を実施した際には、負荷に応じた成功率やレイテンシーなどのパフォーマンス、インフラリソースの使用率などさまざまな指標をチェックし、レポーティングします。特に ML システムでは解析処理に時間がかかったり、GPU など特殊なインフラリソースを使うことも多いため、レポートの内容も複雑化になりやすいと感じています。こうした内容をスキル化することで作業の効率化が期待できます。 キャディではログやモニタリングに Datadog を広く使っているため、 Datadog MCP や Pup CLI を介してログやメトリクスの集計・可視化が行えます。さらに Datadog には Notebooks というドキュメント機能もあるため、これらと Claude Code を組み合わせることで、グラフの描画や考察の記載など含めて負荷試験レポートの作成を簡単に実現できるのではないかと考えています。 今後やりたいこと②：ドキュメントの自動アップデート アプリケーションの実装・実態と、ドキュメントの 整合性のチェックを自動化 できないかと考えています。 リポジトリにおける README などのドキュメントは、開発メンバーのキャッチアップやオペレーション時の資料として非常に重要です。また今回紹介したログ調査やサンプルリクエストなど、コーディングエージェントを適切に動かす上でも、アプリケーションの設定や仕様を適切に整理しておく必要があります。 一方で、こうしたドキュメントは実装やデプロイ環境の実態と乖離してしまい、整備が追いつかなかったり、修正が漏れてしまうこともあると感じています。こうした実装とドキュメントの乖離をコーディングエージェントによって定期的にチェックして、自動でドキュメントをアップデートするような仕組みもできたら面白いと考えています。 まとめ Claude Skills はアプリケーションやチームの知識を AI アシスタントに教え込む有用な仕組みです。私が所属する Analysis Platform チームは必ずしも全員が ML 関連のバックグラウンドを持っているわけではないですが、Claude Skills によって ML システム周りの開発・運用効率が大きく向上したと感じています。 今回は Claude Skills について紹介しましたが、こうしたコーディングエージェントの台頭は不可逆的かつエキサイティングな潮流に感じます。この流れの中で ML 開発をどのように推進していくべきかも注視しつつ、楽しんでいきたいと思います。 キャディでは、ML 基盤の構築・運用に興味のあるエンジニアを募集しています。興味のある方は、ぜひ 採用ページ をご覧ください。

背景 こんにちは、キャディ株式会社D&A部の山﨑広之と申します。 現在、筆者らのチームでは、キャディのミッションである「モノづくり産業のポテンシャルを解放する」ための新しいアプローチに取り組んでいます。具体的には、調達領域の課題解決に向けた仮説検証（フィージビリティスタディ）を通じ、顧客にとっての真の価値を探り当てる新規機能の立ち上げフェーズの真っ只中です。 この検証サイクルが後半に進んだ頃から、顧客へのヒアリングのためにAIエージェントを活用し、デモアプリを作成し始めました。 AIエージェントを使った開発というと「開発期間の短縮」にばかり目が行きがちですが、チームでRetrospectiveをしてみると、実はアプリ作成自体がコミュニケーションや課題解決において大きなメリットをもたらしていると気づきました。 今回は、筆者らが実感した「3つのメリット」についてお話しします。アジャイルに開発を進めている方の助けになれば幸いです。 実際にデモアプリを見せながら説明したいところですがまだ難しいため Retrospective で用いた付箋を見せつつ話したいと思います。 1. チームメンバーが頭に描いているものが同期できる 開発を進めていると、チームメンバーから「こういうのはできないか」と口頭で仮説を提案されることがよくあります。 デモアプリ作成前は、筆者らが頭の中でイメージしながら「できるはずだ」「よさそうなアイデアですね」と回答していました。しかし作成開始後はAIエージェントを活用していることもあり、「じゃあ明日作ってきます」と即座にやりとりし、翌日には実物を見て議論できました。 言葉や図解だけでなく、動くものを中心に議論することで認識のずれがなくなり、より全員が同じ方向を向けます。 振り返りでも、以下のようなポジティブな意見が出ていました。 「動くものがあるの最高」 「Appを通すことでレイテンシー（遅延）を体感できるのがいい」 「自分たちのツールとして使うことで体験が洗練されていく気がする」 💡 AIエージェントの発達で、将来的にはPdMも含めたチームメンバーそれぞれが自分のアイデアをサクッと具現化してミーティングに持ってくる未来も期待しています。 2. 優先度が低い、かつ実現可能性が不明瞭なタスクをまとめて完了できる 「実現可能性が不明瞭だがおそらく問題ないだろう」というタスクが、優先度の関係で保留されることがしばしばありました。 そういったタスクは「問題はない」と思いつつも、100％実現できると言い切れません。未解決の懸念事項として頭の片隅に残り続け、わずかながら認知リソースを消費し、精神衛生上もよくありませんでした。 しかし、今回デモアプリを作成する過程で、これらのタスクをまとめて完了できました。結果として頭のモヤモヤが晴れ、余計なリソースを割かずに「今取り組むこと」だけに集中できるようになりました。 💡 振り返りでも「ダミーとデモをリアルに近づけるフィードバックをしてよかった」という声があり、チームで協力して検証環境の質を上げられたのは大きな収穫でした。 3. 顧客に価値を提供するためにUI/UXからの解決案を提案できる 個人的に一番大きな気づきだったのがこれです。 当初、開発チームの目標は「データの読み取りや、AIが期待通りの出力をする精度を上げること」でした。 しかし、大目的はあくまで「顧客のペインを取り除くアプリを作り、モノづくり産業のポテンシャルを解放すること」です。 AIを用いた技術的なアプローチのみで期待通りの結果を完全に出し続けるのは難しく限界があります。デモアプリがあることで、その限界をUI/UXで対応したり議論したりできました。 課題 UI/UXによる解決案 精度への対応 ユーザーが容易に訂正できるUIにする レイテンシーへの対応 情報の逐次表示やローディングスピナーの工夫により、体感待ち時間をコントロールする また、UXで上記のような工夫をするからこそ、逆に「AIの精度はこれぐらいあれば実用に足る」と精度の線引きを改めて定義できました。 これらの提案は、データの入力・出力のみを行う純粋な精度検証からは得られず、デモアプリを通じたコミュニケーションではじめて得られたといえます。 もちろん、精度向上へのチャレンジも継続して取り組んでいます。 💡 常に「マクロな視点（UI/UXも含めた顧客のペイン解消）」と「ミクロな視点（精度向上の取り組み）」の両輪を意識するよう心がけています。 まとめ デモアプリを作ってコミュニケーションすることのメリットについてまとめます。 メリット 詳細 チームメンバーが頭に描いているものが同期できる 全員が同じ方向を見ることができるようになりました 優先度が低いかつ実現可能性が不明瞭なタスクをまとめて完了できる 余計なリソースを割かずに今取り組むことだけに集中する 顧客に価値を提供するために UI / UX からの解決案を提案できる マクロな視点とミクロな視点を常に意識し解決する AIを使って「早く作る」だけでなく、作ったものを起点にどうチームで対話し、顧客の価値に向き合うかが重要だと改めて痛感しました。 また、このような取り組みを高速に行うことで、プロダクトを届けるまでの時間を短縮できると感じています。 このように、キャディ株式会社では、最新技術を取り入れつつチームで議論しながら一丸となって本質的な課題解決に取り組んでいます。 最後になりますが、AI Agentに関する取り組みや製造業におけるCVに関する取り組みに関しては、他にも以下のようなキャディのメンバーが書いた記事あります。 ご興味あればぜひお読みいただけたら嬉しいです。 AI Agent に関する取り組み caddi.tech caddi.tech 製造業における CV に関する取り組み caddi.tech

はじめに はじめまして。2025年10月にキャディ株式会社へ入社した、エンジニアリングマネージャー（EM）の蟹澤です。 先日、リードアーキテクトの小森（@littleforest12）が、設計フェーズにおける不確実性への向き合い方を綴った記事（ https://caddi.tech/2025/12/16/112311 ）を公開しました。本記事は、同じプロジェクトをプロジェクトマネージャー（PM）として担当した私からの、アンサーソングです。 本プロジェクトは、今後すべてのチームが依存する、キャディの根幹にズブズブと手を入れるような基幹機能開発です。わずかな設計ミスが将来の全社の開発速度を左右しかねない、失敗の許されない横断プロジェクトです。「幅広くキャディを理解する機会として」という意図でのアサインでしたが、当時の私はドメイン知識ゼロ、入社2週間目。正直に言えば「ヒリヒリする打席がきたなあ」と興奮していました。 同時に、冷静に状況を見ると、これは気をつけないとすぐ燃える、火種の多いプロジェクトでもありました。もちろん私もPMとして盛大にプロジェクトに火を噴かせてしまった経験があります。なんなら、新参者の私自身が簡単に火種になり得ます。 そう認識したとき、自分の役割が見えてきました。 チームが自律的に動ける環境を作り、自分がボトルネックにならない 、それがゴールへの最短ルートだと。 結果として、プロジェクトはリリースに向けて（自分でも驚くほど）順調に進んでいます。メンバーに恵まれた部分が大きいのは前提ですが、振り返ると、以下がポイントだったと思います。 アーキテクチャに引いた、責任境界という名の線 2度の設計見直しと、引き返す勇気 仕様的負債をただの「妥協」にしない 「構造を創り、自律を生み出す」がマネージャーの価値 完全な答えを持っているわけではありませんが、同じような状況に置かれた方の、何かヒントになれば嬉しいです。 新参者だった当時の私が「気合と根性の進捗管理」ではなく、「構造の力」でチームを最高速で自律駆動させた、その舞台裏を共有します。 はじめに アーキテクチャに引いた「責任境界」という名の線 二度の設計見直しと、引き返す勇気 仕様的負債をただの「妥協」にしない 「構造を創り、自律を生み出す」がマネージャーの価値 最後に アーキテクチャに引いた「責任境界」という名の線 まず必要だったのは、スケジュールの調整などではなく、アーキテクチャに納得のいく明確な線を引くことでした。 アーキテクトの小森を中心にアーキテクチャの初期検討から進みました。要求の変更も折り込んで複雑度が高まったり、それを整理したりを繰り返します。 合わせてデータモデルも検討していきます。その際、あるメンバーに「DDD的な観点で境界線を引いてみてほしい」と伝えました。 アーキテクチャはオーナーの異なる複数のコンポーネントの連携であり、そこに新しいデータモデルを投入します。自明なところもありますが、当然複雑度は高くなり、極端に言えば 全員が全方位を心配して無限に依存関係を確認し続けるような感じ で、議論が発散しがちでした。 データモデルに引かれた一本の線により考えが局所化し、アーキテクチャにも境界線が表現され、意識の集中は高まり議論が整然と進むようになりました。誰のボールか分からない領域はゼロです。 ここで引かれた線こそ、各チームが持つ「責任境界」です。キャディの組織設計は逆コンウェイ戦略に則っており、コンポーネントとチームとが対になっています。つまりアーキテクチャに線を引くことは、チームの絶対的な安全地帯を定義することです。「他チームの不備の影響が大きいんじゃ？」「グレーゾーンでポテンヒットになるんじゃ？」という 横断プロジェクト特有の漠然とした不安を、アーキテクチャという構造で解消 することができました。 「自分のコンポーネントのことだけ考えていれば大丈夫」 この高い集中を正しく産み出す環境が、チームを最高速で自律駆動させると確信しました。 二度の設計見直しと、引き返す勇気 自信のあるアーキテクチャができ、チームのキックオフを開催しました。アーキテクチャについてCTOとも合意が取れました。設計の詳細化を進めていきます。 そんな中、PdMから「価値提供においてやはり最低限必要だ」と、一度はスコープアウトした要件の見直し議論がおこりました。納期を意識する時点での変更は「火種」です。正直言って避けたい気持ちMAXでしたが、議論により「納期リスクはあるが、中途半端なものを出すことになる」と合理性を理解し、取り込む決断をしました。実現に向けて詳細を詰める中でデータモデルに修正を加え、より実効性の高いアーキテクチャへとブラッシュアップさせました。 「これならいける」と納得し、改めてステークホルダーとの対話に臨みます。 「この修正だと、近い将来の拡張性の毀損や、UXの低下に繋がらないか？」 目の前の仕様に没頭しすぎて生まれた盲点を、正確に射抜くCTOの指摘でした。 「せっかく詳細まで詰めたのに」「納期はどうなる」ピリッとした緊張が走ります。 PMとしては、納期を盾に設計を死守する動きも考えました。しかし、指摘された構造の歪みが将来の現場を疲弊させる。ここで引き返さないと後悔する、という直感に従いました。 盲点になっていた箇所を修正し、影響範囲を洗って全体的な整合が保たれていることを確認。UXレベルでも変更があるためその議論を経て設計修正は完了。CTOとの再レビューでもOKが出て、やっと開発実装に着手する準備が整いました。 こう書くと簡単そうですが、データモデルに手が入っているため、恐ろしく気を遣う工程です。小森さんごめん。 仕様的負債をただの「妥協」にしない ここまで初期設計で当初想定よりも期間を使ってしまい、さらに最後に修正を再度重ねたことで、開発期間は削られた状況でした。 「気合いで間に合わせようぜ！」と無邪気に鼓舞して嫌な顔をされるのは最後の手段にして、納期調整も今回は難しいため、スコープ調整を行います。 要件を一覧化し、要求レベルを評価し、MUSTでなく高難度高リスクな実装項目を一つずつPdMと議論し「後から構造を変えず差し込めるか」等を基準にスコープアウトを決断します。 これ自体は特別変わった風景ではないと思います。（主に心の）痛みや苦い思い出になっていくやつです。 しかし私たちは、スコープアウトした項目をあとから誰も探さないドキュメントに残して終わることを良しとせず、「仕様的負債」であると再定義しました。ここには初期段階でMVPを検討した時に外された要求も含めています。技術的負債であれ仕様的負債であれ、負債は計画的に返済したい。 妥協した項目を「いつかやる」の霧の中に消すのではなく、チームが意識し続けられる構造に置いておく 。それが、今回私たちが大切にしたことでした。 具体的には、全ての負債項目に対して、内容はもちろん、想定される負の影響度合いや解消すべき時期を評価しリストにします。そのリストをPdMや開発メンバーと認識合わせを行い、その上でオフィシャルな開発項目候補としてPdMの管理下としました。バックログの奥底に沈めて終わりではなく、実際に開発検討が進められています。 「構造を創り、自律を生み出す」がマネージャーの価値 構造を整理し、負債の扱いを明確にする。これによりチームは高い集中を得られるはず。 いけると信じていましたが、「開発が進めば仕様調整・納期調整・リスク管理・それらを議論し判断するための会議でカレンダーが埋まるかもな」と言う覚悟も持っていました。一応。念の為。 しかし、デイリーミーティングでの新規リスク報告では、適切な対策案がついてくる。前スプリントでのスケジュール懸念は、リカバリプランに則って次スプリントで見通しがつく。仕様調整や議論は担当同士で完結する。テストが始まっても品質が高い。自分たちの裁量を超える判断はちゃんと相談がくる。チームが自信を持って息づいており、開発が健全に進み続けています。 プロジェクトはもう終盤ですが、安定的な状況にも誰かが気を抜く事もなく、むしろ「今しておけることをやり切っておきたい」といったムードです。 PMとして超人力で奔走する必要などなく、チームがどんどんと自律駆動を続ける。 もしかすると傍目には「あのPM何もしないな」な状態に見えるかもしれません。「ボトルネックになってはならない」という狙い通りであり、 最高の褒め言葉です。ありがとう。 磨き上げた境界線に守られたチームが、自分たちの出すべき価値に集中し向き合えている「高密度の自律」を、このチームが出した成果が証明しています。 チームをこの状態に導けたことは、PMとしてもEMとしても強烈な手応えを感じられる体験でした。そして、「これを実現できるキャディ」でのこれからに、ますますワクワクしています。 最後に キャディに入社早々、こんなにエキサイティングな打席に立つことができました。そして今はまた別のシビれる打席に立ち向かっています。 「構造で高度な自律を引き出す」という挑戦、そしてそれを実現できるメンバー、組織設計、技術戦略がキャディにはあります。 気合と根性ではないマネジメントを手放し、その 熱量をもっと本質的な価値に向けたい欲張りなPM/EMのみなさま。キャディではそんな仲間を募集しています！ 興味を持っていただけた方は、ぜひ採用サイトをご覧ください。カジュアル面談もお待ちしています！ キャディ 採用サイト https://careers.caddi.com カジュアル面談 https://open.talentio.com/r/1/c/caddi-jp-recruit/pages/78398?_fsi=2IcRhEF0

Data Platform 部の森岡です。要らなくなったものをすぐに捨てられるデータ基盤を意識して日々開発しています。 この記事は 「解読データアーキテクチャ」（原題: Deciphering Data Architectures） についての書評となります。 1. なぜ今この本なのか (本文より引用) データメッシュ、データウェアハウス、データレイクハウスといった用語が飛び交っていますが、 10人に「データメッシュとは何か」と尋ねれば、11通りの答えが返ってくるでしょう。 データエンジニアリングの界隈にいれば、「データファブリック」「データレイクハウス」「データメッシュ」という言葉について聞いたことがある人は多いと思います。 しかし、これらの用語には統一された定義があるとは言い難く、ベンダーや専門家の立場によって異なる意味で使われています。 また、それぞれのベンダーのマーケティング的な意味合いを帯びることも多いです。 マーケティング用語だからダメだと言うつもりはありません。重要なのは、こうしたバズワードに振り回されないことです。流行りの言葉をそのまま鵜呑みにするのではなく、「自分たちに本当に必要なものは何か、作るべきものは何か」を自らの言葉で定義し、チーム内の認識を合わせることが、建設的な議論の一歩目となります。 本書は、そのための知識の土台を提供してくれます。 2. 感想 銀の弾丸はない。「トレードオフ」と向き合う 本書は「すべての組織や状況に適用できる万能なアーキテクチャ（銀の弾丸）は存在しない」という前提から出発します。 有名企業が採用しているから、あるいは最近よく耳にする構成だからといった理由でアーキテクチャを選んでしまうと、多大なコストと時間をかけたにもかかわらず、自組織には適合しなかった、という結果になりかねません。 本書を通して繰り返し語られているのは、アーキテクチャ選定を「正解探し」にしてはいけないという点です。著者は次のような考え方を一貫して提示しています。 すべてのアーキテクチャにはトレードオフがある : 流行りのアーキテクチャに飛びつくのではなく、それぞれの長所・短所、そして何を犠牲にするのか（トレードオフ）を理解することが重要。 「技術」ではなく「人とプロセス」 : データプロジェクトの失敗は、技術的な限界よりも、「人とプロセス」の問題や、技術の誤った適用に起因することがほとんど。 絶対の定義ではなく議論の出発点として : 本書が提示する概念は「業界の絶対的な標準」ではなく、あくまで議論を始めるための出発点として提供されている。 この「何でも解決する銀の弾丸はない」というスタンスには非常に共感します。なぜなら、データアーキテクチャにも寿命が存在するからです。 データアーキテクチャの寿命 「データ」自体の価値や寿命は長く続きますが、それを支えるアーキテクチャの寿命はそこまで長くないように思えます。DWHやクラウド製品の移行、ETL/ELTパイプラインやデータモデルの刷新など、多くの企業事例が公開されているのがそれを裏付けています。特に、私が所属するような変化の激しいスタートアップ環境では、その短さをより一層感じます。 だからこそ、アーキテクチャ選定においては「時間スケール」の視点が不可欠です。数ヶ月で破綻するような設計は論外ですが、「このアーキテクチャで3年、あるいは5年戦えるか、また、いざ必要になったときに移行ができるのか」を見極め、適切な設計をするのがアーキテクトだと言えます。 本書でも「データアーキテクチャは段階的・反復的に拡張していくものだ」と主張されており、この点も「寿命を前提として、変化に耐えうる柔軟な設計をしていく」という実務的なアプローチの重要性を感じます。 安易な二項対立からの脱却 データアーキテクチャの議論では、しばしば単純化された「対立構造」が登場します。 たとえば Inmon vs Kimball、データウェアハウス vs データレイクハウス といった構図です。これらは理解を助けるフレームワークとしては有用ですが、実務の意思決定にそのまま持ち込むと誤解を生みやすい側面があります。 本書が主張しているのは、これらを「どちらが正しいか」という対立構造として捉えるべきではない、という点です。現実の企業においては、単一の思想やモデリング手法だけで全要件を満たすケースはほとんどないでしょう。 本書で紹介されているように、Inmonの手法とKimballの手法を組み合わせるアプローチは恐らく珍しいものではなく、多くの組織が暗黙的に採用しているのではないでしょうか。同様に、レイクハウスも既存のDWHやデータマートを完全に置き換える存在というよりは、用途に応じて共存・役割分担されることが現実的だと思います。つまり、重要なのは「どのアーキテクチャを採用するか」ではなく、どの問題を解決するために、どの特性を取り込むかという視点です。 アーキテクチャはイデオロギーではなく、設計における選択の集合です。 理想的な「正解」を探すのではなく、自組織の制約・人材・成長段階に合わせて泥臭く最適解を構築していくのが本質なのだと思いました。 3. この本をおすすめしたい人・そうでない人 おすすめしたい人: データアーキテクト、データ基盤のリードエンジニア CTO / Engineering Manager などの技術的な意思決定者 自社に導入すべきアーキテクチャについて、チーム内で「共通言語」を作りたい人 そうでない人: SQLやPythonの具体的なコーディング方法を知りたい初学者 特定のツール（dbtやAirflow、特定のクラウドサービスなど）の実装チュートリアルを求めている人（本書は「How-to」本ではなく背景と論理を学ぶ本です） 4. 注意点 前述の通り、本書が提供する定義は絶対的な正解ではなく、あくまで「著者の一意見」として読むリテラシーが求められます。 この本をたたき台として、チーム内での共通認識を構築していくことを目指すべきです。 また、特定のベンダーに依存しないニュートラルな立場をとると明記されていますが、著者がMicrosoftに長年所属しているため、無意識にAzureエコシステムの仕様を念頭に置いた評価や制約が含まれている可能性がある点は、差し引いて読むと良いと思います。 5. まとめ 「解読データアーキテクチャ」は、手放しで導入できるような「絶対の正解」は書かれていません。だからこそ、流行りやベンダーのポジショントークに振り回されることなく、「自分たちが作るべきもの」を自分たちの言葉で定義するための思考の土台を与えてくれます。 トレードオフを正しく理解し、自組織の課題や成熟度に合わせて戦略的にデータアーキテクチャを選択したい、すべてのエンジニアやリーダーにおすすめします。 We are hiring また、CADDiでは一緒に働くメンバーを絶賛募集中です! カジュアル面談などお気軽にご連絡ください。 カジュアル面談申し込み_エンジニア・プロダクトデザイナー / キャディ株式会社 Data Engineer / キャディ株式会社 speakerdeck.com