【AI×DevOps Study #21】自律型コーディングエージェントを用いた開発プロセスの最適化

AIxDevOps 自律型コーディングエージェントを用いた開発プロセスの最適化 Supervisory Engineering（監督型エンジニアリング） 2026年8月24日発表者：株式会社Scalar CEO 深津航

開発プロセスの変化従来型の開発プロセス AIエージェントを使った開発プロセス Inner Loop Inner Loop IDE上でコードを書き、ローカルで実⾏し、コンパイルエコード⽣成‧実⾏‧テスト‧修正を⾼速に⾃動化 AIが⾃動化
ラーやテスト失敗を修正する⽇常的な開発サイクル Middle Loop NEW ⼈が評価‧統合‧修正する。AIの出⼒が正しいかを判断する層 Outer Loop Outer Loop コードレビュー、CI/CD、セキュリティスキャン、コンテナ化、ステージング、本番デプロイ CI/CD‧セキュリティスキャン‧本番デプロイボトルネック＝コードを書く速度ボトルネック＝ AIの⽣成物を確認する速度従来の2つのループでは解決できない。Middle Loop によって「⾃働化」と「省⼈化」を実現する必要がある。 AIxDevOps © 2026 Scalar, inc. 1

AIを使った自働化の考え方 - 良いモノをより早く AIが異常な動きをしたら停止する AIが処理を完了したら止まる停止したら処理された内容を確認する（レビューを実施する）開発・工程の標準を決める → 異常が特定できる →
異常が見える（目で見える管理）問題解決につながる変なコードをデプロイしない AIを人の補助にしない品質を工程で作り込む人の仕事とAIの仕事の分離が可能良いシステムが作れるより少ない人数でやれる（工数低減） © 2026 Scalar, inc.

省人化で、 1人日単位で削減する AI駆動開発を始めると、コーディングにかかる時間が大きく削減される。一方、AIに与えるコンテキストの準備、レビュー、意思決定のためのコミュニケーションが効率化のボトルネックになる。 • • • • AIが自立的に意思決定できるコンテキストをしっかり準備する必要がある作られたコードをレビューする時間が長くなる
実装が高速化するため、意思決定のためのコミュニケーション・コストがあがるタスクの依存関係があると、並列に実装を進められないこのため、AIを使ってコーディングするだけでは、開発効率はむしろ下がってしまうなどといった事象が発生する。これに対処するためには、全体の工程を見直し、1人日の仕事を減らせるかどうかを判断軸に、工程を最適化していく必要がある。 AIxDevOps © 2026 Scalar, inc.

「ジャスト・イン・タイム」な開発体制の構築 AI駆動開発では、実装が高速化するため、それに合わせた開発体制の構築と開発プロセスの構築が必要になります。人がやるべきことは「自働化」で、「必要なものを、必要な時に、必要なだけつくったり接続したりする」ことである。これを実現するために、AIを開発工程に組み込み、省力化を行い、省人化を行うことで、一人分の仕事を置き換えることができる。そして、人は、多能化を行うことで、様々な開発工程や技術レイヤーに対応し、「ジャスト・イン・タイム」の実現が可能になる。 AIによる人がやる仕事の変革 •
AIxDevOps 人がやる仕事は、工程を作り込み、出力されるコードの品質を安定させることになる。 © 2026 Scalar, inc.

ドメインごとにチームを作ってコミュニケーションを最適化従来型の開発の場合 AI駆動開発の場合 Frontend Frontend Frontend Frontend Frontend Frontend Backend
for Frontend Backend for Frontend Backend for Frontend Backend for Frontend Backend for Frontend Backend for Frontend Backend Backend Backend Backend Backend Backend 従来はスキルの制約で、技術スタックごとに人をアサインする必要があり、多くの会議体が必要になっていた。 AI駆動開発では、ビジネスドメイン毎にエンジニアをアサインして、開発することができる。 © 2026 Scalar, inc.

AI駆動開発で生産性を上げるためには、部品化と組み立て指示が重要標準化された部品を AIが組み立てる「ソフトウェア工場」にする • 人が、何を部品化するのか、アーキテクチャを設計し、ソフトウェア工場の生産ラインを構築する。 • 部品を組み立てる実装は、AIが行い量産化
することで効率化する。マイクロサービスアーキテクチャごとに部品を組み⽴てる © 2026 Scalar, inc.

Middle Loopとは Middle Loopは、AIエージェントが解決策を提示した瞬間から始まり、それを CI/CDへ流すまでの間にある、人間による評価・統合・修正の工程です。ここで人間のエンジニアは、単にコードの文法を確認するのではなく、次のような判断を行います。 • • •
• • AIは本当に正しい問題を解いたか要件や意図に合っているか既存アーキテクチャから逸脱していないか複数のAIエージェントが生成した成果物を整合的に統合できるか本番環境へ流して安全な変更かつまり、Middle Loopは、人間の判断力と AIの実行速度が接触する層です。この層を監督するのが、 Supervisory Engineering（監督型エンジニアリング）です。 AIxDevOps © 2026 Scalar, inc.

Supervisory Engineeringとは Supervisory Engineeringは、単にAIの作業を眺める役割ではありません。人間がAIへ仕事を適切に分解して渡し、出力を評価し、必要に応じて修正させ、システム全体として成立させるエンジニアリング活動です。 Supervisory Engineering は、以下の4つの役割を持ちます。 •
• • • 意図と制約を揃える複数エージェントの成果物を統合するコードの書き方より振る舞いを評価する CI/CD前のゲートとして機能する AIxDevOps © 2026 Scalar, inc.

AI駆動開発の生産性を向上させるプロセス AI駆動開発を効率的に行うには、”自働化”を行い”省人化”することを目指す AIが最適にコードを生成できるように準備する要件定義仕様調査適用領域見極めエージェント準備実装テンプレート開発制約・監視・管理の準備
トライアル＆最適化開発準備この行程を高速かつ大量に処理できるように最適化する設計詳細設計開発（実装）テスト一次レビュー結合＆レビュー人が監視 AIが主導人が主導振り返りドキュメント生成 1人日の仕事を削減できるかどうかを指標にし依存性スラックと、リソーススラックを削減していく AI駆動開発では、一部を効率化するのではなく、全体のスループットを向上させる © 2026 Scalar, inc. E2E テスト

局所最適化を制御するためのタスク管理方法 AIに指示を行うと、与えられたコンテキストの中での最適化が行われるが、全体の整合性を考慮しないことが多い。このため、局所最適化に陥らないようにするための仕組みが必要になる。この問題に対処するために、指示を Epic → Sub Epic → Issue
という形で階層化し、 Epic 全体での最適化を指示する。それぞれの役割は以下の通り。 Epic Sub Epic Issue 役割記述する内容 Epic 並列実装可能な依存関係がない機能ドメインの要求 What, Why, Success Metrics, Sub-Epics, 進める順序、Non-Goals, Traceability, Source Sub Epic Epic を構成する要件 What, Key Results, Why, Issues, Traceability Issue 具体的な実装タスク Why, What, Acceptance Criteria, Notes, Traceability Sub Epic Issue Issue AIxDevOps © 2026 Scalar, inc.

アンドンとポカヨケを、AI駆動開発の工程に組み込む異常を検知して⽌める仕組み（アンドン）と、間違いを作り込ませない仕組み（ポカヨケ）を、Epic / Issue と MR に埋め込むアンドン｜異常を検知して、その場で⽌める
ポカヨケ｜間違いを作り込ませない TPS: 異常が起きたら紐を引き、ラインを⽌めて全員に知らせる TPS: そもそも間違えられないように、⼯程に仕掛けを作るエンジニア AI エージェント Epic プロンプトで対話しながら実装を進める Sub Epic Issue 各階層にチェックリスト（完了条件）を組み込む逸脱（⼩）異常（⼤） AI が⾃⼰チェックプロンプトで即座に是正 Issue を起票して⽌めるチェックリストと成果物を⾃ら照合して完了を報告する⼈が判断｜⽌めた内容を確認し、ルールへ反映する⼈が確認｜チェック結果と成果物をレビューして合否を判断実装が完了したら MR を作成し、チェックリストを出荷基準として出荷判定を⾏う異常はその場で⽌め、品質は⼯程で作り込む © 2026 Scalar, inc.

安定したコード品質を保つために、AIの特性を知る得意なタスク • • • • • • • 不得意なタスク
パターンが確⽴している実装⾔語‧フレームワーク間の翻訳リファクタリング‧可読性改善説明‧ドキュメント⽣成定型的なデバッグ短くて検証しやすいコードスニペットサブエージェントを使った並列実装モデル • • • • • • • • • ⼤規模でなじみのないコードベース全体の理解ニッチ‧新しめのライブラリの正確なAPI 並列性‧レースコンディションパフォーマンスチューニング UI/UXの視覚的判断⻑時間の反復デバッグビジネス判断がカラム設計数値計算の厳密性指⽰の遵守、⻑い会話の後のコーディング 1モジュールの推奨⾏数上限⽬安備考 Haiku 4.5 150〜300⾏ 500⾏関連ファイルを数個⾒るとコンテキストが飽和する Sonnet 4.6 200〜500⾏ 800⾏通常の実装に最適（CRUD処理） Opus 4.7 200〜500⾏ 800⾏複雑度の⾼い実装に最適（複雑なビジネスロジック） © 2026 Scalar, inc.

Inner Loop の品質を高めるためには • コンテキストを小さく保つための方法 ◦ ◦ マイクロサービス・アーキテクチャの採用マイクロサービス間の整合性を担保する •
非機能を分離する ◦ セキュリティ実装を外部化する • 実装を分割しつつ、局所最適化を回避する ◦ 境界コンテキストで最適化する AIxDevOps © 2026 Scalar, inc.

AI駆動（Claude Code）で開発したときの実験結果従来の開発⼿法で、⼈が開発した場合の想定⼯数 • 総⼯数「推定 1,220時間」、開発期間「推定 6〜9ヶ⽉」 AI駆動開発：モジュラーモノリス AI駆動開発：マイクロサービス開発期間：
約3ヶ月開発期間：約3週間総工数：約900時間総工数：約56時間このシステムの中核となるOrderServiceクラスが責務過多な巨⼤クラスになり、「物理的には分散‧論理的には密結合」な分散モノリス構造になってしまった。最初から、ビジネスドメインを明確化し、ビジネスドメインごとにマイクロサービス化することで、責務を超えた巨⼤クラスを回避。ただし、実装品質のブレを抑える必要があった。 ※ドメイン間の整合性は、ScalarDBで担保 © 2026 Scalar, inc.

モノリス/モジュラーモノリスの課題 AI駆動開発を高速かつ効率的で安定した状態で実施するためには、マイクロサービスアーキテクチャが最適モノリス/モジュラーモノリスマイクロサービス AI Agent 機能が独立しており、並行して高速に開発することができる。
観測マイクロサービス単位で観測することができる AI Agent 対象のコード以外も修正してしまうリスクがある。また、コンテキストが大きくなるため、コード全体が破壊される可能性が高くなる。観測 AI Agent 大きな機能単位での観測になり、ボトルネックを見つけにくい。対象のマイクロサービスのみに注目して修正が行われる。コンテキストも小さくなるため、コード全体が破壊されるリスクが小さく、テストも高速に行える。 © 2026 Scalar, inc.

マイクロサービス間の整合性がなぜ課題になるのか AI駆動開発での課題起きがちな問題対処方法分散トランザクションで重要なのは正常系ではなく catch してログだけ出す。タイムアウト時の状態判状態遷移表＋異常系一覧＋補償仕様込みで指示異常系だが、AIはこれを考慮しない。定がない。補償処理が未実装。再試行時の重複排
する必要がある。除がない。局所最適化をめざすため、サービス境界を壊してし他のサービスのDBを直接読み書きする。内部状態サービスの責務を単一にして指示する。まう。に依存した分岐を書く。API契約を飛ばして実装す他のサービスの内部を隠蔽する。る。べき等性を落としてしまう。同じ要求が二回行うと壊れる AIは単純化する傾向があり、「状態不明」を表現しな中間状態を無視し、SUCCESS/FAILEDで実装すい。る。タイムアウトを考慮しない。各操作毎に、独立したキー・ビジネスキーの定義、重複時の処理方法、再入時の期待する結果を指示する。起こりうる状態をあらかじめ定義し、状態遷移モデルを指示する。補償TXを「逆処理」と誤解する。決済取消処理を決済前に戻してしまう。通知送信は業務補償処理を明確に定義して、処理方法を細かく取り消せないが、取り消そうとする。指示する。原子性を壊す処理を書いてしまう。 2つのサービスの更新を別処理で書いて、片方だけあらかじめ起こりうる状態を定義し、それぞれの状が失敗することを考慮しない。態に対する処理を指示する。 AIは異常系を考慮せず単純化してしまう傾向がある、人が具体的な処理方法を細かく指示する必要がある。ただし、異常系の処理を細かく指示するとコードが肥大化する © 2026 Scalar, inc.

AIが落とすのは、分散トランザクションの異常系サービスをまたぐ更新は、正常系だけ⾒れば単純な⼀本道になる AIが数分で書けるのは、ここまで注⽂サービス注⽂を確定在庫サービス在庫を引き当て決済サービス決済を実⾏完了
実際には、この⼀本道からいくつもの異常系が分岐する⽚⽅だけ成功する応答が返ってこない補償処理が失敗する再実⾏で⼆重になる在庫は引き当てたが決済で commit の結果が不明。再送打ち消すための処理そのも冪等でなければ、タイムア競合。確定済みの更新をどすれば⼆重に計上されるのが落ちたときの復旧⼿順ウト後のリトライが実害をう戻すか出す正常系はAIが数分で書く。落ちるのは、その先の分岐異常系は業務ごとに違い、明⽂化もされていない — だからAIも⼈も落とすこの⼯程を⼈が毎回ゼロから設計している限り、AIに任せられる範囲は広がらない © 2026 Scalar, inc. 1

マイクロサービス間のつなぎ方と整合性ドメイン同⼠の繋がり⽅（Context Map）を8つの型で分類する。型の選択が、そのままトランザクション設計の前提になるパターンどういう関係か Partnership 対等な⽴場で共同設計する求められる整合性使いどころ∕注意点強整合
同⼀チーム∕実質1つのBCになりやすい Customer / Supplier 上流が提供し、下流が利⽤する同期API∕結果整合も可社内の責任分担∕上流変更が下流に波及 Conformist 下流が上流モデルに完全に従う上流依存‧強整合外部SaaS‧単純参照∕モデル汚染の危険 Anti-Corruption Layer Shared Kernel 上流モデルを⾃分の⾔葉へ翻訳する盾⼀部のモデルを共有する結果整合∕Sagaで実装外部連携∕実装が複雑で肥⼤化する強整合共通概念のみ∕肥⼤化すると結合地獄 Published Language 公開契約（API‧イベント）で連携結果整合が基本∕Saga向きイベント駆動∕契約の肥⼤化に注意 Open Host Service 上流が安定したAPIを公開する同期中⼼∕外は結果整合公開API∕トランザクションの抜け漏れ不要相互依存がない∕障害時に不整合の恐れ Separate Ways 統合しない関係の型を選ぶことは、必要な整合性を選ぶこと強整合を求める型は、DBを分離した瞬間に成⽴しない ─ ScalarDB がそこを基盤側で吸収する © 2026 Scalar, inc. 1

ScalarDB は、分散トランザクションの型を基盤側で提供するアプリで毎回⾃前実装していた整合性の担保を、選べる3つの型に置き換える 2PC（Consensus Commit） Saga TCC 提供中 3.19 で提供
3.19 で提供強整合（ACID）結果整合結果整合（予約つき） begin → CRUD → prepare 各サービスのローカル処理を → validate → commit 順に実⾏する prepare が1つでも失敗すれば、全 participant を rollback する失敗したら、そこまでの処理を補償トランザクションで打ち消す Partnership / Shared Kernel / Conformist ── 強整合が要る関係 Anti-Corruption Layer / Published Language ── 結果整合で回す関係 Try で資源を仮確保する確定なら Conﬁrm、取り消しなら Cancel で解放する在庫‧座席‧与信など ── 先に押さえてから確定する業務どのモデルを使うかは、Context Map で決めた関係の型から決まる設計上の判断が、そのまま実装の型になる ※ Saga / TCC は ScalarDB 3.19 で提供予定 © 2026 Scalar, inc. 2

異常系が有限の型に閉じるから、AIに実装させられる業務ごとに考えるものだった異常系が、決まった分岐と決まった⾻組みになる例外は3つの分岐に閉じるモデルごとに、異常系の⾻組みが決まる prepare が1つでも失敗すれば、 CommitConflictException CrudConflictException rollback して
リトライする 2PC UnknownTransaction StatusException rollback しない状態を後から照合する Saga その他の TransactionException rollback する TCC どれに当たるかで、取るべき動作が⼀意に決まる全 participant を rollback。 commit は1つ成功すればコミット扱いになる失敗したステップまでの処理を、補償トランザクションで逆順に打ち消す Try で確保した資源を Cancel で解放する。確定済みなら Confirm 済みとして扱うモデルを選んだ時点で、書くべき異常系が決まる分岐が有限になる判断が定型になる⾻組みは基盤側にあるプロンプトにも規約にも書き切れるレビューは型どおりかの確認で済む AIが書くのは業務ロジックだけになる © 2026 Scalar, inc. 3

アクセス制御と暗号化は、レビューで守れない AIに書かせたかどうかに関わらず、アクセス制御と暗号化の実装が正しいかは、⽬視レビューやコードレビューだけでは担保できない ① 正しさが全称命題 ② 失敗がサイレント「この主体は、このデータに到達できない」という否定形。書い認可漏れも暗号化漏れも、正常系は完全に動く。ユニットテストてあることは読めるが、書かれていないことは読めないも
E2E も通る。動作から区別できない ※正しさが全称命題とは「すべての範囲や場合において常に真（正しい）」ということです。 ③ 正解がコード側にない ④ 横断的で⼀様性が要る「この操作を誰が実⾏してよいか」は業務要件。リポジトリのど全エンドポイント‧全フィールドに⼀様に効いて初めて成⽴すこにも書かれていないので、判定の根拠がないる。1箇所の抜けで全体が破れる AIで変わるのは難しさではなく、量と速度もともとレビューで守れていなかったものが、⽣産量で破綻する AIxDevOps © 2026 Scalar, inc. 1

一様性が要るから、局所最適化と最も相性が悪いアプリケーションに実装した場合 ── 認可と暗号化は、全経路に効いて初めて成⽴する POST /orders 認可 ✓ ∕ 暗号
✓ GET /orders/{id} 認可 ✓ ∕ 暗号 ✓ POST /payments 認可 ✓ ∕ 暗号 ✓ GET /payments/{id} 認可 ✓ ∕ 暗号 ✓ POST /invoices 認可 ✓ ∕ 暗号 ✓ GET /invoices/{id} 認可 ✗ ∕ 暗号 ✓ GET /customers 認可 ✓ ∕ 暗号 ✓ PUT /customers/{id} 認可 ✓ ∕ 暗号 ✓ この1箇所が抜けても、正常系は全部動く。ユニットテストも E2E も通るレビューが⾒る範囲正しさが成⽴する条件 Issue #27 の差分＝ 1エンドポイント分のコードすべての経路 × すべてのロール × すべてのデータ⼀様性は全体の性質。Issue 単位のレビューでは、原理的に⾒えない AIxDevOps © 2026 Scalar, inc. 2

ScalarDB が提供するセキュリティ機能 ScalarDBの持つセキュリティ機能を⽤いてアプリケーションの関⼼事から外す機能何ができるかユーザ∕ロール∕GRANT‧REVOKE。テーブル単位の粗粒度認証‧認可 Keycloak 等が発⾏した JWT
を RFC 9068 準拠で検証し、ScalarDB ユーザへマップす OIDC / JWT る ABAC （レコード単位） Enterprise Premium Enterprise Premium policy‧level‧compartment‧group のタグをユーザとレコードに付け、⼀致したと Enterprise Premium きだけアクセスを許す Option TDE 相当。書き込み前に暗号化し、読み出し時に復号する。クライアント設定の変更カラム暗号化エディションは不要 Enterprise Premium ScalarDBのセキュリティ機能を⽤いることで、データアクセスに対するセキュリティの実装は、アプリケーション層から、インフラ層に集約することができます。 AIxDevOps © 2026 Scalar, inc. 4

守る場所が、アプリケーションから基盤へ移る同じ3サービス‧同じ3データベースで、認可と暗号化がどこに置かれるかアプリケーションに実装する注⽂認可＋暗号のコード決済認可＋暗号のコード ScalarDB
に寄せる請求認可＋暗号のコード注⽂サービス共通の層がないため、 PostgreSQL RLS を個別設定請求サービス ScalarDB Cluster 認証 / OIDC ‧ ABAC ‧ カラム暗号化各サービスが各DBの流儀で個別に実装する MySQL RLS を個別設定決済サービス DynamoDB RLS を個別設定 MySQL PostgreSQL DynamoDB 認可と暗号化がアプリに散在し、DBごとに個別設定が要る 1回の設定が、全DB‧全アクセスに⼀律に効く 1箇所の抜けは、コードを読んでも⾒えないアプリのコードに認可も暗号化も現れない「レビューで⾒つける」から「そもそも書かせない」へ AIxDevOps © 2026 Scalar, inc. 5

4つの理由のうち、 3つが構造的に片づくレビューが難しかった理由に、1つずつ当ててみるレビューが難しかった理由判定 ScalarDB を使うとどうなるか認可ロジックがコードから消え、タグ定義になる。宣⾔的で⼩さく、全体を⼈間が ① 正しさが全称命題
解決 ② 失敗がサイレント部分的 ③ 正解がコード側にない残るタグ設計そのものが業務判断。ただし判断の量は減り、⼀箇所に集約される ④ 横断的で⼀様性が要る完全に解決 ScalarDB を通る全アクセスに⼀律に効く。1箇所の抜けが原理的に起こりえない読める暗号化はコードに現れないので漏れが起きない。認可は「タグ付与の漏れ」として形を変えて残る局所最適化と最も相性が悪かった④が消える ── ここが最⼤の効き⽬ AIxDevOps © 2026 Scalar, inc. 6

消えるのではなく、守る面が縮む縮んだ⾯には、依然としてゲートが要る守る⾯：認可‧暗号化の実装コード全体残る⾯タグ付与なぜ残るかどう守るかレコードにタグを付けるのは、結局 INSERT 時のア
タグ列を NOT NULL＋既定値∕付与の網羅テスト∕未プリコード設定レコードの検出 ABAC も暗号化も ScalarDB Cluster の機能。直接DB 迂回経路接続‧バッチ‧レプリカ‧バックアップには効かない OIDC の粒度鍵管理に縮むこの4つだけ ScalarDB を唯⼀の⼊⼝にする。DB認証情報を配らず、ネットワークで閉じるドキュメントは「1⼈以上の OIDC ユーザ → 1つのエンドユーザ単位で⾏を分けるなら 1:1 マッピングが ScalarDB サービスユーザ」を想定している要る。要件と運⽤規模を先に確認する self-encryption は DEK をテーブルごとに Secrets の暗号化‧RBAC‧External Secrets を別途設 Kubernetes Secrets に置く計するレビューで守れないものを外し、残った分を宣⾔とゲートで守る AIxDevOps © 2026 Scalar, inc. 7

AIは、与えられたコンテキストの中で最適化するエージェントは渡された範囲では妥当な解を出す。範囲の外は⾒えていない Issue を単体で渡すと Issue #12 注⽂APIを追加それ単体では妥当 Issue #27
在庫APIを追加それ単体では妥当 Issue #41 決済APIを追加それ単体では妥当 3つを並べた瞬間、揃っていないことが分かる抽象が重複する流儀が割れる名前が割れる既存のリポジトリ層に気づかず、似たものエラーを例外で返すもの、戻り値で返すも同じ概念が Order / Purchase / をもう1つ作るのが混ざる Transaction と呼ばれるこれは能⼒の問題ではなく、⾒えている範囲の問題局所最適の集合は、全体最適にならないだから「どの範囲で最適化させるか」を設計する必要がある © 2026 Scalar, inc. 1

階層を作っただけでは、出力は揃わない Epic → Sub Epic → Issue のツリーは、整合性の必要条件であって⼗分条件ではないツリーを作っただけの状態 Epic
整合性を⽣んでいるのは、この2つ ① 決定が成果物として固定されている境界‧インターフェース‧データモデル‧エラー⽅針が、 Sub Epic 動かせない形で存在している Issue #123 エージェントが読むのはこの本⽂だけ ② 実⾏時に必ずコンテキストへ載る上位で決めたことは、実⾏時のコンテキストに⼊っていない ── ツリーの存在は、エージェントには⾒えない CLAUDE.md ∕ 規約ファイル ∕ 参照必須の設計書 ∕ 型定義やスキーマそのもの階層は「どこで決めるか」を決める器にすぎない決定を下位へ運ぶ経路は、階層とは別に作る必要があるツリーを作ることと、決定が届くことは別の問題 © 2026 Scalar, inc. 2

整合性の種類ごとに、効く手段が違う階層でしか解けないものと、階層では解けないものがある整合性の種類何が揃わないか効く⼿段構造的インターフェース∕依存⽅向∕ データモデル上位で決めて固定する。最も強いのは契約をコードで表現する ──
型‧スキーマ‧OpenAPI‧proto にすれば、AIは逸脱できなくなる規約的命名∕エラー処理∕ログ階層ではなくゲートで強制する ── Linter と CI に検査させるほうが、Epic に書くより確実意味的同じ概念が別の名前で呼ばれるユビキタス⾔語を成果物として持ち、常にコンテキストへ載せる ── ⽤語集が実⾏時に読まれる場所に置かれているか⽂書で「こう書け」と指⽰するより、AIが逸脱できない形にするほうが強い © 2026 Scalar, inc. 4

Epic は決める場所、Issue は作る場所「Epic 単位で最適化する」は「Epic 全体をエージェントに渡す」ではない階層 Epic Sub Epic
Issue そこで決めること境界の切り⽅∕インターフェース∕ データモデル∕エラー⽅針分割の単位と依存順∕契約の具体化実装のしかた成果物設計書‧型定義‧スキーマコンテキストの広さ広い（決定だけを出す。コードは書かない） API 定義‧テーブル定義‧テスト中（決定の範囲内で詳細化す仕様る）コード狭い（前提は凍結済み。広げる必要がない）コンテキストを広げるほど、注意は拡散して精度が落ちる広げるのは「決めるとき」だけ。作るときは狭いまま整合させる決定が凍結されていれば、Issue はコンテキストを狭く保ったまま揃う © 2026 Scalar, inc. 3

境界コンテキストで最適化する上位で整合を取るより、整合を取る必要が出ない切り⽅を選ぶほうが強い注⽂ドメイン機能で切る境界コンテキストで切る Epic：決済機能 Epic：注⽂コンテキスト（ScalarDBで結合を指⽰）在庫ドメイン
決済ドメイン注⽂ドメイン在庫ドメイン決済ドメイン 1つの Epic が複数のドメインをまたぐドメイン間の整合性は、ScalarDBを⽤いる → Issue 間で整合を取り続ける必要が残る → 整合性をルールで担保できる Epic単位で、検証を⾏うことで、正しく実装されているかをチェックできる依存⽅向のテスト∕スキーマ差分∕API 契約テスト ── これが無いと、確認⼿段が⽬視レビューだけになる ScalarDBを使うルールを強制することで、ドメイン間の整合性を保つために、ドメインをまたがった設計からAIを開放することができる © 2026 Scalar, inc. 5

Epic / Sub Epic / Issue で最適化する Issue を AI
にタスクのゴールを渡し、Epic, Sub Epic で整合性をチェックする仕組みを構築する Epic / Sub Epic にタスクの依存関係、強制ルール、クライテリアを設定し、ゲートを設けることで、AIが自立的に実装することができるようになる。 Epic Sub Epic Issue #123 Plan Check Work Review Compound Review Backlog Epicごとに機能を整理し、Sub Epic / Issue でタスクを細分化することで、整合性を保った状態でAIがコードを書くことができるようになる © 2026 Scalar, inc.

AI駆動開発では、開発プロセスの発想を変える必要がある従来型の開発要件定義設計 AI駆動型の開発要件定義/設計開発・テスト開発テストリリース
AI駆動型の開発の特徴リリース • 開発期間：数日〜 • 変更回数：小さな差分が高頻度 • 依存関係の複雑さ： AIがまたいで編集しがち • レビュー／監査で確認すべき対象： SBOM、依存ライセンス、脆弱性など開発・テストを高速に実行するマイクロサービスごとに並列実装機能設計実装テストレビュー機能設計実装 E2E テストレビュー AIxDevOps © 2026 Scalar, inc. 「共通基盤」がないと、AIが生成する変更を安全に早くリリースするための統制の仕組み（DevSecOps）とコスト配布の仕組み（FinOps）がないと運用とコストが破たんする

対策の頻度が上がる前提で、仕組みを先に用意する AI は攻撃側の圧⼒と開発側の速度を同時に上げた。対策も同じ速度で回す形に変える課題 1 守る対象と更新の頻度が増え続ける課題 2 従来の対策が、速い開発の⾜を引っ張る AI
の進歩でリスクが上がり、パッチ適⽤とフレームワークの更新を AI で開発サイクルが⾼速化するほど、従来型の対策が開発‧リリー頻繁に⾏う必要があるスのボトルネックになる従来の進め⽅のままでは、セキュリティ対策が開発とリリースの⾜かせになる 1 共通基盤に寄せる 2 共通基盤テストで⾃動化を⽀えるテストカバレッジ 95% 以上 3 機能単位で出せるようにする⼀括機能機能機能個々にインフラを作らず共通基盤に集約し、同カバレッジ 95% 以上を確保し、パッチ適⽤とマイクロサービス化し、機能ごとにテストとデ⼀基盤上で運⽤‧監視するバージョンアップを半⾃動化するプロイを回す頻度が上がる前提で、共通基盤‧テスト‧分割を先に⽤意しておく AIxDevOps © 2026 Scalar, inc.

AI時代のインフラ：デプロイの独⽴性の担保ビジネスの変化、リスクの変化に柔軟に対応していうことが難しい重複したコードや資産が余計なリソースを消費する
モノリスなので、開発は容易だが、規模は大きくなりがち構築運用会社ごとに、運用マイクロサービスアーキテクチャでまとめて運用アプリケーション単位でまとめて更改していく機能単位で随時更新・更改していく統合基盤個別個別 Kubernetes システムをほとんど停止せずに、リリースすることができる Frontend API Gateway (Kong) API App App App Frontend API API API App API Gateway (Kong) 機能の再利用性が高く集約するとコスト効率が高くなる API API API API ScalarDB VMs HW HW 統合DB（RDBMS）個別DB 個別DB AIxDevOps コンポーネント間の整合性を保ちデータアクセスをまとめて管理 VMs Managed Database (RDBMS, NoSQL) © 2026 Scalar, inc.

Outer Loop を仕組みにして⾃働化する必要がある従来の開発 Inner Loop コードを書く‧動かす‧直す Outer Loop レビュー‧CI/CD‧デプロイ
リリース判定を人が行う AIエージェントの導⼊ AI駆動開発 Inner Loop AIが⾃動化（分単位） Middle Loop ⼈が評価‧統合‧修正（時間単位） Outer Loop 検証‧反映‧観測‧是正（⽇〜週単位）投⼊頻度が桁で上がり、⼈⼿で回している側から詰まる Inner Loop の速度が上がるほど、その外側を仕組みにできているかが効いてくる脆弱性‧テスト‧SLO‧コストを⾃動で判定し、⼈が⾒るのは例外だけでよい判断を「都度の⽬視」から「宣⾔されたゲート」へ移すこと。ゲートを設計するのが⼈、ゲートを通るのがAI。 AIxDevOps © 2026 Scalar, inc.

Outer Loopの6つの⼯程変更が本番に届き、その結果が次の指⽰に返るまでの⼀周 ① 検証 ② 配布 ③ 反映 ④
観測 ⑤ 判定 ⑥ 是正 PR/MRごとに脆弱性‧テストを⾃署名してTest環境へ出し、E2Eで通す ArgoCDがGitの状態へ⾃動で同期するメトリクス‧ログ‧ トレースを集める SLOと残バジェットで合否を出す Runbookで対処し Issue に起票する動判定する観測した結果が次の指⽰に戻って、はじめて⼀周する Outer Loop は「デプロイまで」ではない。この⼀周が⾃動で閉じているかどうかが、Middle Loop に張り付く⼈の量を決める AIxDevOps © 2026 Scalar, inc. 5

Outer Loop の 6⼯程と AIDD Infra テンプレートの対応 AIxDevOps © 2026
Scalar, inc.

運⽤成熟度は5軸 × 4段階で測る「監視ツールが⼊っているか」ではなく「運⽤として回っているか」で評価する観点 Lv1 属⼈ Lv2 標準化 Lv3
⾃動化 Lv4 ⾃律可観測性ログのみメトリクス整備 3本柱を集約相関分析で根因特定 SLO / アラート閾値なし⼿動で閾値設定 SLO をコード化エラーバジェット運⽤インシデント対応属⼈対応⼿順書を整備通知経路と抑制を設計⾃動復旧と定期訓練回復性 / DR 未整備バックアップのみ復旧⼿順をジョブ化訓練済み‧RTO 実測コスト / セキュリティ事後に精算⽉次で確認常設ダッシュボード逸脱を⾃動検知 5 つの観点はそれぞれ独⽴して評価する。全軸が同じ段階に揃っている必要はなく、弱い軸から順に引き上げる AIxDevOps © 2026 Scalar, inc.

可観測性の3本柱を単⼀スタックに集約メトリクス‧ログ‧トレースを1つの収集層から取り、1つの画⾯で突き合わせる収集レイヤー Grafana Alloy node-exporter kube-state-metrics Beyla（eBPF）全 Pod
のログ‧ メトリクスを収集ノードの CPU / メモリ / ディスク Pod‧Deployment の状態アプリ改修なしでトレースを⾃動⽣成保管レイヤー活⽤レイヤー Prometheus Loki + S3 Tempo + S3 メトリクス保持 14 ⽇ログ保持 7 ⽇トレース保持 72 時間 Grafana Pyrra Alertmanager ダッシュボードで横断的に可視化 SLO を評価し違反を検知重⼤度別に Slack へ通知トレースからログへ、ログからメトリクスへ相互にジャンプできるようラベル体系を揃えている AIxDevOps © 2026 Scalar, inc.

保持期間とサンプリングを調査可能性で設計「いつまで遡れるか」「何を必ず残すか」を、シグナルごとに決めているシグナル基盤保持期間冗⻑構成主な⽤途メトリクス Prometheus 14
⽇ 1 系統 SLO 評価‧アラート判定‧容量計画ログ Loki + S3 7⽇ 2 系統障害時の原因追跡‧アクセス監査トレース Tempo + S3 72 時間 2 系統レイテンシのボトルネック特定ログ量は「捨ててよいもの」だけを削るトレースは 30% サンプリング ‧2xx かつ未認証のリクエストのみ 30% に間引く ‧トレースとログのサンプリング率を同⼀に揃える ‧4xx / 5xx と認証済みリクエストは全件保持 ‧同じリクエストを両⽅の系統で追跡できる ‧障害調査の材料と侵害検知の識別情報を落とさない ‧保管コストを抑えつつ再現性を維持する保持期間‧サンプリング率はいずれも設定値として⼀元管理し、環境ごとに変更できる AIxDevOps © 2026 Scalar, inc.

SLO を YAML で宣⾔し⾃動監視している⽬標値はコードとして管理され、変更は GitOps 経由で即座に反映されるゲートウェイ可⽤性ゲートウェイ
レイテンシ分散トランザクション 95% P95 < 400ms 99.5% 5xx エラー率 < 5% 達成率 95% エラー率 < 0.5% 全 API リクエストの成功率認証経路を除いたアプリ体感 ScalarDB の全操作成功率 SLO をコード化することで得られるもの ‧計測窓は 7 ⽇。⽬標値は 1 ファイルの数値を書き換えるだけで変更でき、レビューの記録が残る ‧エラーバジェットの消費速度（バーンレート）に応じた多段アラートを⾃動⽣成する ‧レイテンシ SLO は認証基盤の経路を除外し、アプリケーションの体感を正しく測る AIxDevOps © 2026 Scalar, inc.

重⼤度で経路を分け連鎖通知を抑制する「何が起きたか」より先に「今すぐ⼈を呼ぶべきか」が判別できる状態にしている検知ルール 17 本 Critical @channel 付き / 1
時間ごと再通知 Warning メンションなし / 4 時間ごと Cost コスト逸脱 / 24 時間ごと ‧ワークロード（5） ‧証明書ライフサイクル（5） ‧ランタイム保護（2） Alertmanager ‧バックアップ（1） ‧ゲートウェイ / DB（2） ‧GitOps / ノード供給（2）抑制ルール — 1つの障害を1つの通知にまとめる ‧ノード障害を検知したら、その配下で連鎖発⽕する Pod のアラートを⾃動で抑え込む ‧証明書の更新失敗時は、同じ証明書の期限切れ警告を重複させない ‧常時発⽕する死活監視⽤アラートは通知先を持たせず、通知の信頼度を保つ AIxDevOps © 2026 Scalar, inc.

復旧は3段階の CI ジョブとして⼿順化済み障害の規模に応じて実⾏するジョブを選ぶだけで、復旧⼿順が再現できる⽇次バックアップ 01 Namespace 復旧全 Namespace
を毎⽇ 1 回‧保持 14 ⽇で取得。失敗時は即座に重⼤アラートが⾶ぶ 02 クラスター全体復旧 03 全損からの再構築想定: 特定 Namespace の破損想定: クラスター規模の障害想定: クラスターごと消失対象を限定して短時間で戻す全リソースをバックアップ時点へ基盤再作成 → 復旧 → 検証を⾃動化影響範囲を絞った最⼩の復旧順序制御はジョブ側が担保シークレット基盤も⾃動復帰誤操作を防ぐガードレール ‧実⾏権限は保護環境で管理者に限定し、同⼀環境での同時実⾏は排他制御される ‧復旧元のバックアップは⼀覧ジョブで⽇時を確認してから指定する運⽤に統⼀している AIxDevOps © 2026 Scalar, inc.

毎週、負荷とカオスを同時に流して検証する「壊れたときに戻るか」を机上ではなく実測で確認し続ける ramp up 負荷テスト ramp down steady（88 分）障害注⼊
5 シナリオ × 各 10 分（間に回復期間）ノード中断負荷が最も⾼い区間でノードを1台強制中断させる 0分 30分 60分 90分前段ゲート終了後の⾃動レポート ‧軽量なスモークテストに合格した場合のみ ‧SLO 逸脱‧発⽕アラート‧エラー率を突き合わせ本番相当の負荷へ進む⼆段構えにしている結果を統合レポートとして⾃動投稿する AIxDevOps © 2026 Scalar, inc. 110分

コストとセキュリティも同じ監視⾯に載せる可⽤性だけでなく、費⽤と脅威も同じダッシュボードとアラート経路で扱うコスト可視化ランタイム保護クラウド脅威検知 ‧クラスターのコストを常時推定 ‧カーネルレベルで異常挙動を検知 ‧クラウド側の脅威検知と連携 ‧専⽤ダッシュボードを 3
種常設 ‧重⼤度に応じて即時通知 ‧⾼深刻度のみを選別して通知 ‧時間あたり∕前⽇累計を⽇次で共有 ‧監視対象は全ノードに常駐 ‧通知失敗も検知できる⼆重化平⽇毎朝、状況サマリを⾃動投稿している ‧SLO 達成率（分散トランザクション成功率 / ゲートウェイのエラー率） ‧インフラ健全性（異常な Pod 数 / 未 Ready ノード数） ‧発⽕中のアラート件数と、クラスターの時間あたり∕前⽇累計コスト AIxDevOps © 2026 Scalar, inc.

Staging までは Lv3、Production は監視基盤の可⽤性含めて構築する仕組みは揃っている。残る課題は「監視が落ちたときに気づけるか」 Lv1 Lv2 Lv3 Lv4 可観測性
Lv3 SLO / アラート Lv3 インシデント対応 Lv3 回復性 / DR Lv2 コスト / セキュリティ Lv3 監視基盤そのものが単⼀構成のため、基盤が停⽌すると障害の発⽣⾃体が⾒えなくなる。また回復性は⼿順が整備済みでも訓練が未実施のため Lv2 に留まる AIxDevOps © 2026 Scalar, inc.

Level 4 へは3つの重点施策で到達するどれも「新しいツールの導⼊」ではなく「既にある仕組みの本番化」 01 監視基盤を冗⻑化する 02 アラートを本番⽔準へ 03 回復性を定期検証する
‧監視系を単⼀構成から冗⻑構成へ ‧メトリクス⽋損そのものを検知 ‧復旧訓練を定期実施し実測値を取る ‧可視化基盤の状態を外部に保持 ‧コスト逸脱アラートを実装 ‧⽬標復旧時間を数値で合意 ‧監視基盤⾃体を監視対象に含める ‧重⼤度別に通知先を分離 ‧カオス試験の対象を段階的に拡⼤監視が落ちても気づける⾒逃しと通知過多を同時に減らすこの3つで何が変わるか ‧「気づけない障害」を無くす — 監視の停⽌‧メトリクスの⽋損‧費⽤の逸脱を検知対象にする ‧「戻せるはず」を「戻せる」に変える — 訓練による実測値で復旧時間を合意できる状態にする AIxDevOps © 2026 Scalar, inc. 復旧時間を数値で⾔える

3フェーズで本番運⽤⽔準へ引き上げる検知の網羅性 → 基盤の可⽤性 → ⾃律運⽤、の順に積み上げる Phase 1 Phase 2
Phase 3 〜3ヶ⽉：検知の網羅性〜6ヶ⽉：可⽤性と訓練〜12ヶ⽉：⾃律運⽤へ ‧メトリクス⽋損の検知を有効化 ‧監視基盤を冗⻑構成へ移⾏ ‧エラーバジェットでリリース判断 ‧コスト逸脱アラートを実装 ‧復旧訓練を定期実施し実測 ‧カオス試験の常時実⾏化 ‧データ層のイベント監視を追加 ‧通知経路を重⼤度別に分離 ‧他クラウド環境へ横展開到達: Lv3 を全軸で揃える到達: 本番運⽤の前提条件各フェーズは前フェーズの完了を前提としない。検知の追加は既存構成のまま着⼿できる AIxDevOps © 2026 Scalar, inc. 到達: Lv4 ⾃律運⽤

事例：AI駆動開発プロジェクトでの運用実態出典: GitLab Security Dashboard（2025-12-12 〜 2026-08-04‧全 29 週‧detectedAt 基準）
288 件総検出 26 件 Critical 90 件 High Critical High Medium 11 件 Other Low Info Unknown 98 100 運用中のシステムでの脆弱性検出の件数スキャナの拡充後 Claude Mythos / Fable 5 Release 75 50 45 Claude Mythos preview Release 25 21 17 19 0 12/8 12/15 12/29 1/5 1/12 1/19 1/26 2/2 2/9 2/16 2/23 3/9 3/16 3/23 3/30 4/6 4/13 4/20 5/4 5/11 5/18 5/25 6/1 6/8 6/15 6/22 6/29 2 つの⼭（5/18‧7/20）は新規発⽣ではなくスキャナ拡充による⼀括検出。定常ペースは週 1〜10 件、うち Critical / High が 1〜3 件 AIxDevOps © 2026 Scalar, inc. 7/20 8/3

リリース後のセキュリティ対策従来の「リリースまで守る」から、「リリース後も守り続ける」へ ── 対策の考え⽅を変える AI による総当たり型の探索 ── 脆弱性は公開前から突かれ、運⽤中も出続ける 1 使う限り、直し続ける
2 運⽤が続く限り、新しい脆弱性は出続けるデータは分けて置く 3 重要度で分類し、物理的に分けて置く即⽇パッチを回す検知から適⽤までを当⽇中に回す 1箇所に集約＝抜かれると全損リリース ! ! 検知 ! 運⽤（使い続ける限り）機密社内公開修正テストこの⼀周を当⽇中に完了させる ‧⾃社開発もローコードも対象 ‧集約は便利だが、抜かれると全損 ‧テストカバレッジ 95% 以上 ‧「作って終わり」では守れない ‧重要度の分類が前提になる ‧テストを⾃動化して即検証 ‧機能単位でパッチを適⽤ ‧パッチ提供が続く製品を選ぶリリース後も「検知 → 修正 → テスト → デプロイ」を⽌めずに回せる状態を、仕組みとして持つ AIxDevOps © 2026 Scalar, inc. デプロイ

事例：セキュリティパッチの作成・適用の自動化 GitLab Scheduler の定期実⾏から本番デプロイまで、脆弱性対応の⼀周を⾃動で回す ① 検知 ② 起票 ③ 修正と検証
④ 出荷毎⽇⾃動実⾏⾃動で Issue 化 AI ＋⾃動テスト⾃動＋⼈の判断 1回 GitLab Scheduler 毎週定期実⾏セキュリティ Issue 作成 Claude Code でセキュリティパッチ⽣成 E2E テストを実⾏脆弱性チェック GitLab Vulnerabilities API 脆弱性の⾃動修正 Issue 脆弱性の再スキャンステージングへデプロイ脆弱性あり？ Security Fix Issue 作成単体テストを実⾏⼈がデプロイ許可なし → 終了 ∕ あり → ② へ対応の履歴が Issue に残るコードをマージ本番へデプロイ（Blue/Green）テスト NG‧脆弱性が残る場合は Claude Code へ⾃動で差し戻しこの⼀周が毎週⾃動で回るので、クリティカルな脆弱性にも即⽇でパッチを当てられる AIxDevOps © 2026 Scalar, inc.

AI駆動開発のための AIエージェント Supervisory Engineering を実現するための AI エージェントを公開（nexus-architect）しています。これを用いることで、Inner Loop を自働化し、人は、
Middle Loop をまわすことに専念できます。 AIxDevOps © 2026 Scalar, inc.

nexus-architect は「設計の⼿順」をエージェントに実装した道具である汎⽤チャットではなく、成果物‧順序‧検証が決まった 88 本の実⾏可能な⼿順書何であるか何を作るか何が決まっているか Claude Code
/ Codex ⽤のプラグイ reports/ の設計⽂書、generated/ 各スキルの出⼒ファイル‧実⾏順序ン。3 つに分かれた 88 個のスキルのコード、トラッカー上の Epic / ‧前提条件‧検証⽅法‧担当モデル（実⾏可能な⼿順書）でできている Issue、マージ済みの Pull Request が、すべて宣⾔的に定義されている対応する仕事の範囲プロダクト構想 UX と仕様システム設計実装と納品ビジョン‧指標‧収益‧スペルソナ‧ジャーニー‧UI ドメイン分割コード⽣成‧バックログ化‧ コープ‧仮説検証モック‧機能‧データモデル ‧API‧ScalarDB‧インフラ‧ 実装‧レビュー‧マージセキュリティ AIxDevOps © 2026 Scalar, inc.

設計の失敗は「速さ」ではなく「抜けと不整合」から起きる汎⽤の AI ⽀援では埋まらない 3 つの⽳が、nexus-architect の存在理由設計は⼯程が多く、順序に依存する。調査を⾶ばして再設計に⼊る、⾮機能要件を数値化しないま抜けるま実装する⸺抜けは後⼯程で最も⾼くつく。
→ 88 スキルが⼯程を明⽰し、依存グラフが順序を守る⽂書が増えるほど、⽤語‧ID‧図の参照がずれる。1 つずつは正しくても、束ねると⽭盾する。⾷い違う → 5 観点の並列レビューと⾃動フックが機械的に検出する設定キー‧API‧バージョンをモデルの記憶で書くと、もっともらしいが誤った実装が混ざる。根拠が曖昧になる → バージョン固定の公式ドキュメントとレジストリ実測で裏を取る速く書くことではなく、抜けなく‧⾷い違わず‧根拠を持って書くことが⽬的 AIxDevOps © 2026 Scalar, inc.

同じ設計作業が「属⼈の⼿順」から「再現できる⼯程」に変わる価値は速度そのものではなく、成果物の⼀貫性と、判断の根拠が残ること Before — 属⼈の設計 After — nexus-architect × ⼯程の順序と抜けはレビュアーの記憶に依存する
◦ 依存グラフが順序を保証し、抜けたフェーズが分かる × ⽂書の粒度と章⽴てが担当者ごとに違う ◦ 全成果物が同じ frontmatter と章構成で出⼒される × 設計とコードが別々に進み、乖離に後で気づく ◦ 同じ PR にコードとドキュメントが⼀緒に載る × ライブラリのバージョンは記憶とコピペで決まる ◦ レジストリ実測 + 決定表で版数の根拠が残る × 設計書は書かれるが、着⼿可能な単位にならない ◦ Epic / Sub-Epic / Issue まで分解されて着⼿できる⼀貫性追跡性説明可能性同じ形の成果物が毎回出る要件 → 設計 → コード → PR が ID で繋がるなぜその判断かがファイルに残る AIxDevOps © 2026 Scalar, inc.

4 つの⼊⼝があり、案件の状態に応じてどこからでも⼊れる全部を通す必要はない。持っている材料に合う⼊⼝を選ぶ構想しかないレガシーがある要件が固まっている ScalarDB だけ使いたい /product:start /architect:start
/architect:define-requir /scalardb:build-app ements ビジョンから仕様まで作調査 → 分析 → 評価 → 再新規設計の⼊⼝。FR/NFR レポートツリー無しで、動り、そのまま architect の設計 → マイクロサービス分類と ScalarDB 適⽤判定くアプリを直接組み上げる要件定義へ渡す化計画までから想定する使い⼿アーキテクト開発リードコンサルタント設計判断と、その根拠の記録バックログ化と実装の駆動調査‧評価‧⾒積の成果物作成 AIxDevOps © 2026 Scalar, inc.

3 つのプラグインが構想‧設計‧ScalarDB 実装を 1 本の線でつなぐ個別に使えるが、product → architect → scalardb
の受け渡しが設計されている product architect scalardb 26 51 11 skills skills skills 構想 → 検証 → 仕様分析 → 設計 → 納品 ScalarDB 開発の道具箱 ‧ビジョンと North Star 指標 ‧調査‧MMI / DDD 評価 ‧スキーマ設計ウィザード ‧仮説検証ゲートで Go/No-Go ‧マイクロサービス再設計 ‧6 インタフェースの雛形 ‧UI モックと React ⽣成 ‧5 観点の並列レビュー ‧例外処理‧CRUD / JDBC ‧ドメイン / API / SLA‧NFR ‧バックログ納品まで駆動 ‧16 観点のコードレビュー 3 プラグインは同じ番号で同時にリリースされる AIxDevOps © 2026 Scalar, inc.

Outer Loop のための AIDD Infraテンプレート AWS/Azure/GCPで動作するAI駆動開発のためのインフラのテンプレート（近日公開予定） AIでは担保できない品質検証のゲートを設けており、非機能をカスタマイズ可能なインフ
ラテンプレート • • • • AIxDevOps © 2026 Scalar, inc. GitLabベースで構築 API Gateway は Kong を使用 ScalarDBは事前セット済みそれ以外は、Kubernetes + OSSベースで構築

Please give us a star on GitH ub! udy AIxDevOps
St 毎週⽕曜開催 GitHub scalar-labs/scalardb connpass Scalar AIxDevOps © 2026 Scalar, inc.

【AI×DevOps Study #21】自律型コーディングエージェントを 用いた開発プロセス...

【AI×DevOps Study #21】自律型コーディングエージェントを 用いた開発プロセスの最適化

More Decks by Scalar, Inc.

Other Decks in Technology

Featured

Transcript

【AI×DevOps Study #21】自律型コーディングエージェントを用いた開発プロセス...

【AI×DevOps Study #21】自律型コーディングエージェントを用いた開発プロセスの最適化