【20260423 AI×DevOps Study Meetup #1】コードからプロセスへ：AI時代の開発パラダイム ―実行と改善、2つのプロセス設計―

■AI×DevOps Study Meetup #1の概要
2026年4月23日に開催した「AI×DevOps Study Meetup」第1回の開発チームの発表資料です。

「AI×DevOps Study」は、AI駆動開発やそこに関係するマイクロサービスについて理解を深める場になります。
株式会社ScalarではAIを使ったチーム開発を進めており、参画しているメンバーや協力会社の方から、具体的なAI駆動開発を実施する方法、その中で生まれたマイクロサービスアーキテクチャを使用したAI駆動開発の事例や実際に使えるエージェントについてお話頂き、参加者の皆様と知識の共有や交換を目的としています。
（弊社製品であるScalarDBも絡んだお話も一部出てきますが、汎用的な内容となっておりますのでフラットにお楽しみいいただけます）

■今回のテーマ
「コードからプロセスへ：AI時代の開発パラダイム ―実行と改善、2つのプロセス設計―」
AIを導入することによる開発プロセスの変化や考え方についてお話します。

■登壇者情報（敬称略）
奥野晃裕（開発チーム）
Scalarのシニアソフトウェアエンジニア。博士（情報理工学）。東京大学生産研究所、AlpacaDBなどでデーターベース・データ基盤の研究開発を経て現職。Scalarでは、ScalarDBでの分析問い合わせを実現するScalarDB Analyticsの開発に従事。

■関連コンテンツ
・Youtube（過去の勉強会動画も公開中！）
www.youtube.com/@scalar-labs

・Zenn ブログ
https://zenn.dev/p/scalar_sol_blog

・イベントページ（connpass）
https://scalar.connpass.com/

Transcript

1. コードからプロセスへ：AI時代の開発パラダイム ― 実行と改善、2つのプロセス設計 ― Akihiro Okuno AI×DevOps Study Meetup #1 — 2026/4/23
2. AI導入の現場で起きていること 速くなったのは確か。しかし同時に： 仕様未確定のまま、AIが「それらしいコード」を生成 → そのまま通過 出力が膨大で、レビューが「眺める作業」に形骸化 手戻り・仕様逸脱・レビュー差し戻しで工数が膨らむ 問題発生時、 「AIが書いたので」で責任が宙に浮く ▼ 実装は速くなった。しかしデリバリーは速くなっていない。 2
3. 開発プロセスの構造変化 従来: 仕様策定 ──→ 実装 ──→ レビュー ──→ デリバリー ( 実装を通じて仕様理解が深まる。一貫して人間が責任を持つ) AI 導入: 仕様(?) ──→ AI 実装 ──→ セルフレビュー ──→ チームレビュー ──→ デリバリー ↑ 曖昧 ↑ 速い ↑ 判断根拠が薄い ↑ 量が膨大 速くなったのは実装だけ。前後の負荷はむしろ増加 実装を通じた仕様理解の機会が失われ、レビューの判断力が低下 レビューが二段階必須に（セルフレビュー + チームレビュー） 開発プロセスの構造が変わった。プロセスの再設計が必要。 3
4. AIが変えたもの、変えられないもの AIは開発を大きく変えた。実装、調査、試作 — 多くの領域で高速化し、今後さらに広が る。 しかし、AIに委ねられないものがある。 「基準を定める」行為。 仕様定義 — 何を作るべきか。ビジネス価値やニーズの判断 品質評価 — これで十分か。基準そのものの設定 保守設計 — プロダクト全体の一貫性と将来の見通し AIは基準に従って実行できる。基準を定めるのは人間。 AIは開発を加速する。しかし「開発者」ではない。 4
5. 「基準をどう伝えるか」— 新しい設計領域 人間が定めた基準を、AIの実行に正しく反映する — AI時代に生まれた新たな設計課題。 Prompt Engineering — 指示の設計で出力を制御 Context Engineering — AIに渡す文脈を設計 Harness Engineering — 出力の制約・検証を設計 アプローチが収束していないこと自体が、この領域の重要性と難しさを示している。 Harness Engineering: Mitchell Hashimoto (2025) ｜ ※ vibe coding（基準を定めずAIに委任）は継続的開発に不適 5
6. 設計領域の2つの軸 — 実行と改善 アプローチが収束していない以上、自ら実行し、改善するループを回すことが重要。 実行プロセス 基準をAIの実行に反映し、 タスクを遂行する ↻ 改善プロセス 実行の結果から学び、 実行プロセスを進化させる 6
7. 実行プロセス 基準をAIの実行に反映し、 タスクを遂行する ↻ 改善プロセス 実行の結果から学び、 実行プロセスを進化させる 7
8. 仕様の明確化 — 実行プロセスの土台 AIは曖昧な仕様でも実装に進む。仕様が曖昧なら、コンテキストもハーネスも機能しな い。 何をなぜ作るのか — 人間にしか定義できない、AIへの最も重要な入力。 仕様策定と実装のフェーズ分離が構造的な対策 AIと仕様を詰めるのは有効。ただし実装とは区切る 曖昧さが残る＝実装に進めないゲートを設ける 仕様が曖昧なまま実装を始めると、AIは「正しいもの」ではなく「それらしいもの」を作 る。 ※ SDD（Specification-Driven Development） 、Claude Code Plan、Kiro等、ツールレベルでもこの領域が重 視されつつある 8
9. コンテキスト設計 — 実行条件の設計 仕様はAIへの最も重要な入力。しかしそれだけでは足りない。 コンテキスト ＝ AIに渡す情報全体。タスクの実行条件セット （≠ チャットの会話ログ） 過剰 余計な情報 → 判断の焦点がぼやける 前タスクの残滓 → 意図外の影響 不足 必要な制約の欠落 → 的外れな出力 既存設計の未共有 → 整合性の破綻 ▼ 「多ければ良い」は誤り。情報の過不足を設計する。 9
10. ハーネス設計 — 委譲の前提条件 制約をかける ≠ AIを信用していない 制約をかける ＝ 安心して任せるための前提条件の設計 ハーネス 役割 テスト 期待する振る舞いを定義し、逸脱を自動検出 型チェック・Lint 構造的な制約を自動で強制 Sandbox 実行環境の制限。意図外の操作を防止 レビューゲート 人間の判断が必要なポイントの明示 人間のレビューを「全部見る」から「判断が必要な箇所に集中する」へ。 10
11. ↻ 改善プロセス 実行の結果から学び、 実行プロセスを進化させる 実行プロセス 基準をAIの実行に反映し、 タスクを遂行する 11
12. なぜ改善プロセスが重要か 自然言語と確率的動作の壁 — 指示に曖昧さが残り、出力も毎回揺れる。一発で意図 通りにはならない 手法の急速な陳腐化 — 半年前のベストプラクティスが今は古い 現場ごとの違い — 開発プロセス自体がチーム・プロダクト・技術スタックで異なる ▼ 意図と出力のギャップを観察し、仕様の伝え方・コンテキスト・ハーネスを調整し続け る。 12
13. AI時代のプロセス改善 プロセス改善自体は新しい概念ではない。変わったのはプロセスの記述方法。 従来 プロセスは暗黙知、Wiki止まり 書いても読まれず、属人化 改善しても定着しない → AI時代 プロセスをコンテキストとして 記述できる 記述がそのままAIへの実行指示 になる 更新すれば挙動が即変化 記述の更新がAIの挙動に即反映される。 実行と改善のサイクルが高速に回り、プロセスの進化スピードが従来とは根本的に異な る。 13
14. 実践例：開発ワークフローの設計 14
15. 開発ワークフローをAgent Skillとしてパッケージ化 Agent Skill = AIの振る舞いを定義する再利用可能な指示セット。 開発ワークフローの各フェーズをSkill化し、 実行プロセスの3要素と改善プロセスを組み込んだ。 15
16. ワークフロー全体図 kickoff → spec → plan → implement → self-review → user-review → post-task フェーズ プロセスとの対応 kickoff → spec 仕様の明確化 — 曖昧さを実装前に排除 plan コンテキスト設計 — セッション跨ぎでも実行可能な文書 self-review ハーネス — AIが自分で合否判定 user-review レビューゲート — 人間の最終承認 post-task 改善プロセス — 知見を蓄積し次に活かす 16
17. フィードバックによるプロセスの改善例 観察されたギャップ プロセスへの反映 見積もり間違いが頻発する Task→Story昇格を「失敗」ではなく正常経路として設計 セッション跨ぎで文脈が消える ドキュメントを唯一の真実とし、会話ログに依存しない 主観的な完了基準はAIに判定できない 「わかりやすい」ではなく操作的に定義する 仕様を完成させてから実装、は非現実的 仕様を「進化する文書」として改善前提で設計する Plan Modeがワークフローの文脈を失う ツール自体をプロセス設計の制約として考慮する 17
18. 結論 18
19. コードからプロセスへ プロセスが「ドキュメント」から「実行系」へ。 設計と改善の質が、AIの出力品質を決める時代。 ▼ 競争力を決めるのは、どのAIを使うかではなく、どうプロセスを設計し改善するか。 明日からできること： 仕様を決めてから実装に入る。フェーズを混ぜない AIの出力が意図と違ったとき、直す指示を出すのではなくプロセスを見直す 19
20. Thank you Akihiro Okuno AI×DevOps Study Meetup #1