Cognition AIJapan - Webinar 1: 上流工程

Transcript

1. 2026 Why Devin for 上流工程 自律的AIエージェントが要件定義・設計・開発までを一貫して支援
2. 2026.08.26 / HAMAMATSUCHO CONVENTION HALL DevinCon 26 / Tokyo 345 173 47% 参加者数 参加企業数 従業員1,001名以上の企業 最終参加確認ベース 事業会社 58% / SIer・受託 42% 48% が経営・管理／技術リーダー層 主な参加企業（173社より抜粋） セッション登壇企業（13社） 三菱重工業 / NTTデータMHIシステムズ / ワークスアプリケーションズ / DeNA AI Link / freee / カカクコム / サイバーエージェント / タイミー / AI inside / みずほ証券 / 三菱UFJ eスマート証券 / ULSコンサルティング / ファインディ（共催） トヨタ自動車 / KDDI / NTTデータ / NTTドコモ / 富士通 / 東芝 / パナソニック / 村田製 作所 / ニコン / スズキ / LINEヤフー / MIXI / SmartHR / Sansan / DMM.com / 野村 総合研究所 / みずほ銀行 / 三井住友カード / サントリーホールディングス / 日本放送 協会 / 大日本印刷 / 伊藤忠テクノソリューションズ / SCSK / 豊田通商 / Microsoft / Meta Japan 出典：2026年8月27日提供の最終版参加者一覧（参加確認済み345名・173社）。構成比は登録時アンケート回答者ベース。 Proprietary & Confidential DEVINCON 26 / TOKYO 2
3. Proprietary & Confidential 3
4. SCOPE 上流工程の5工程：新規開発と追加開発 同じ「実装前」でも、グリーンフィールド（新規開発）は決めていく作業、ブラウンフィールド（追加開発・刷新）は現行を調べて捨てる作業が主になる。 グリーンフィールド（新規開発） ① ブラウンフィールド（追加開発・刷新） 事業目的、価値仮説、投資対効果、Go/No-Go判断 定 構想 ② To-Be業務フロー、業務ルール、体制・組織要件 要件定義 ④ 基本設計 As-Is調査（アセスメント）：現行機能一覧の再構築、DB・IF棚卸し、 データプロファイリング、課題・リスク一覧。To-Be業務フロー、業務 ルール、体制要件（踏襲／改善の判断） 要求定義 ③ 刷新目的（EOL／保守コスト／事業変更追随）、対象システムの選 機能要件一覧、非機能要件（想定値）、概念データモデル。スコープ 刷新範囲（境界）の確定、現行機能の処遇判定（継続／改修／廃 はMVPへ絞り込む方向 止）、差分要件、非機能要件（実測値ベース）。 方式設計、技術選定・PoC、機能設計、画面・帳票設計、DB論理設 上記に加えて、移行設計（新旧共存方式、データ移行、切替・切戻 計、外部IF設計、運用設計 し条件）、既存側システムの改修設計、連携先システムとの調整 詳細設計、製造、単体〜総合テスト 上記に加えて、移行リハーサル、並行稼働、回帰テスト （仕様書） ⑤ 詳細設計・開発 作業見積もり・工数算出は各工程に併走する。実装後の仕様書追従・突合・テスト生成は価値が高いが、上流工程ではなく隣接領域として区別する。 Proprietary & Confidential 4
5. BACKGROUND 日本のSW開発において上流工程が重視される理由 上流工程が重い理由は、生産性の問題ではなく構造の問題である。発注・分配・刷新・保守のいずれも、文書の精度がそのまま後工程のコストになる。 01 02 外部に発注する側 開発を分配する側 内製チームを持たない企業は、外部の開発会社に依頼するために緻密な 開発会社は、社内やパートナーへ作業をスケーラブルに割り振るために、 要件定義を用意する必要がある。曖昧さは見積の膨張、仕様解釈の相違、 正確な設計書へ落とす必要がある。設計書の粒度と精度が、同時に着手で 手戻りとして必ず返ってくる。 きる人数の上限を決める。 03 04 レガシーを刷新する側 作ったあとを支える側 コードは存在しても仕様が存在しないケースが多い。現行仕様の再構築に 開発が進んでも仕様書が更新されない現場では、サポートや業務部門が現 膨大な調査コストがかかり、着手そのものが先送りされる。刷新の可否判断 行の挙動を理解できない。問い合わせ対応、教育、次の改修の調査コスト が止まる。 に転嫁される。 Proprietary & Confidential 5
6. Devin 公式ウェビナー 開催予定 devin.connpass.com ランチタイム開催（12:00–13:00）／ オンライン ／ 参加無料 ／ 主催: Cognition（Devin開発元） 9/16 （水）12:00–13:00 オンライン開催 内容（予定） 10/7 （水）12:00–13:00 オンライン開催 内容（予定） • 仕様書 → 実装のライブデモ（ PR作成まで） • テスト・QAのAI化（自動生成・自動保守） • AIに伝わる要件定義・設計のコツ • 運用・監視の AI化（障害の一次対応） • Q&A（Cognitionメンバーが回答） • 導入事例の紹介と Q&A こんな方に • 上流工程に関わるエンジニア、PdM・その他ご担当社様 こんな方に • SRE/運用チーム、技術責任者、QAエンジニア Proprietary & Confidential 6
7. 2026 Devinのご紹介
8. クラウドエージェントがAI開発を次の次元に 自律型開発エージェント 「開発を丸投げ」 複雑なマルチステップタスクを 自己完結的に非同期で実行 対話型開発エージェント 自律性 「作業を依頼」 IDE・CLIでペアプログラミングしなが らローカルで作業を実施 タブ補完 シンプルな提案、時間節約に なるが推論能力は不足 Local IDE Wave 1 Local IDE Local IDE Devins ‧ In VPC AIがコードを提案してくれる 個人を拡張する チームを拡大する ~10% 効率向上 ~30% 効率向上 何倍ものアウトプット Wave 2 Wave 3 ソフトウェア開発の進化 Proprietary & Confidential 8
9. DevinはSDLCの各ステップを担当する エージェント群が協調して開発を進める ローカル AI エージェント <20% エンジニアがコード作成に 費やす時間の割合 Devin: クラウドエージェント 既存コード理解 開発計画 コード生成 Proprietary & Confidential レビュー＆テスト メンテナンス 9
10. ⽣成AIを核にした⾃律型開発エージェントの開発 対話型ツールを⾮同期‧⾃律型エージェントとして運⽤するには、ハーネスの上に基盤レイヤーの構築が必須になる 実⾏ハーネスと実⾏環境 統合レイヤー 外部ツール連携（Git, Slack, CI/CD, MCP）‧イベント駆動 オーケストレーション VM管理‧サブエージェント管理‧並列実⾏‧ループ開発 = サンドボックス 隔離されたmicroVM‧ネットワーク制御‧Secrets セキュリティ‧運⽤ ガードレール‧監査‧ユーセージ管理‧更新への追随 対話型開発エージェント エージェントハーネス コンテキスト管理‧ツール実⾏ - Claude Code, Codex etc LLM Claude, GPT, Kimi, GLM, SWE etc Proprietary & Confidential 10
11. Devinの競合優位性 自律型の AIエージェント SDLC全体をカバー する機能提供 基盤モデルからの 独立 エンタープライズ要 件実装 最先端のハーネスエンジニ アリング がAI SWエンジニア との共同作業を実現 既存コード分析・理解 Deep Wiki タスクに応じて最適なモ デルを自動で選択 設計 Ask Devin 特定のラボに依存せず パフォーマンス維持しな がら50%以上コスト削 減。 デプロイメント シングルテナント環境 SSO対応・データ所有権 SOC 2等認証準拠 先進的なマイクロ VM構成で 人間の生産性に縛られるこ となくクラウドエージェント が リモートでタスクを並列処理 開発・テスト・デプロイ Devin Session レビュー Devin Review 保守 Devin Automation 開発タスクに特化した小 型・軽量モデル(SWE)を 自社開発 Proprietary & Confidential コラボレーション 組織単位の権限管理 共同作業機能の充実 ノウハウの共有 Cognitionの専任DEが利用 促進と効果検証を支援 11
12. 自律型エージェントと対話型AIの使い分け グリーンフィールド ブラウンフィールド グリーンフィールド、ブラウンフィールドの分類だけでは見えてこない適正を、3つの軸で判定する A 検証可能性が高い B 成否を機械が判定できるか（テスト・ CI・lint・型） 量・反復性が高い C 失敗コストが低い 捨てて再実行できるか。一手が不可逆でないか 同型のタスクが何件あるか 自律型AIに向いている開発 対話型AI＋人間に向いている開発 A・B・Cの3軸がそろう仕事 ─ 機械が判定でき、数があり、失敗を捨ててやり直せる そろわない軸が残る仕事 ─ 右端の記号は満たせない軸 仕様の明確な新規開発 探索的なプロトタイピング 受け入れ条件とテストを書ければ、 0→1でも委譲できる 作りながら仕様を発見する。正解が事前に決まらない 既存システムからの仕様・業務フロー起こし 原因の見当がつかない深いデバッグ 大量のコードベースを正として仕様に起こし、幅広いデータを統合して業務フローを推定 仮説と観測の反復が主戦場。再現手順が書けたら委譲できる 言語・フレームワークの一括マイグレーション UI・体験・ブランド表現 既存テストが正解を定義し、スライスに割れる 「良い」の基準が人間の中にしかない セキュリティー脆弱性検出・修正 アーキテクチャ・技術方針の決定 定期的に脆弱性検出を実施し、即時対応 トレードオフの判断そのものが成果物 テスト追加・カバレッジ拡大 本番データなど不可逆な操作 本番コードに触れず、対象ファイル数だけ量がある 調査と手順書までを渡し、実行は人間 バグのトリアージとチケット消化 未知技術の学習 再現手順があれば機械判定に落ちる。件数が多い 委譲のオーバーヘッドの方が大きい Proprietary & Confidential A・B A A A・C C B
13. USE CASES 上流工程のどこでDevinが使われているのか Devinユーザーのユーセージメタデータ分析に基づく 構想・要求定義 要件定義・PRD 基本設計仕様書 リポジトリを読ませて改善要求を要求仕様書に起こす 要求定義書から要件定義書へ展開（工程を段階で分けて 実行） 画面・バッチ・リアルタイム処理の基本設計書を提案・作 成 As-Is調査：現行機能一覧の再構築とDB・IFの棚卸し 新規プロダクトのPRDを作る／PRD文面をレビューする 画面ID単位で一括作成（逐次実行で章立てと用語を揃え る） 旧Excelの要求仕様を解析し、記述の抜けとリスクを洗い 出す 刷新範囲の境界と現行機能の処遇判定、差分要件の整 理 移行方式の検討と、既存側・連携先の改修範囲の洗い出 し 詳細設計 作業見積もり 上流の品質保証 画面ID・API単位のUI詳細設計書、クラス図設計書の作 成 チケット単位で影響範囲を調査して工数を算出 要件定義書・設計書のレビューと指摘リスト化 既存詳細設計書の最新化・章立て整合・重複排除 ブランチの残作業を洗い出して見積もる 基本設計→詳細設計→実装の網羅性レビュー 基本設計の変更を詳細設計書へ波及させる 移行方式ごとの工数比較と実装・切替計画の提示 用語統一・矛盾検出（上流成果物そのものの検査） 注：件数はセッションタイトルの日本語キーワード一致による集計。品質保証はレビュー・網羅性・整合の語を含むものの再集計で他工程と重複する。 Proprietary & Confidential 13
14. CAPABILITIES 上流工程で効くのは、この5つの機能の組み合わせ 既存を調べる（DeepWiki／Ask Devin）、成果物を作る（Session）、正しさを担保する（Devin Review）、様式を固定して回し続ける（Playbook＋Automation）。 DeepWiki 既存コードを継続的に索引する Ask Devin 現行仕様への質問に出典で答える Session 実行環境で成果物を作り切る Devin Review 御社の規約で一次レビューを回す Playbook ＋ Automation 様式を固定し、人の着手を待たない リポジトリの構成・依存関係・データフローを定期的にインデックスし、図と出典付きで参照できる。仕様書が存在しないレガシーでも、 As-Is調査の起点を「根拠付きの現行仕様」から始められる。 「この帳票はどこで生成されるか」「この項目の算出ロジックは何か」に、該当箇所を示して回答する。要件定義中の確認を、有識者の 空き時間に依存せず進められる。 隔離環境でリポジトリを読み、要件定義書・設計書・見積を作成して PRまで出す。記述を実物で確かめられるため机上推測にならな い。子セッションで画面 ID・機能単位に並列化できる。 仕様書の PRをREVIEW.mdの組織規約で審査し、曖昧表現・章立ての抜け・記載漏れを指摘する。機械的に直せる指摘は Auto-Fixで 修正し、人は判断が必要な箇所に集中できる。 章立て・粒度・用語を Playbookで固定し、スケジュール・ PRマージ・チケット起票をトリガに自動実行する。書式ブレを抑え、「ドキュメン ト整備プロジェクト」を常時稼働のプロセスに置き換える。 上流工程のセッションでは、調べる機能と作る機能を同じ文脈で往復できることが効いている。 Proprietary & Confidential 14
15. PATTERN A｜上流 型① 要求・要件から設計・チケットへ展開する 要求定義書を起点に、要件定義→基本設計→詳細設計→チケットまで落とす。 01 02 03 要求を読み込む 疑問点を先に出す 基本・詳細設計へ 要求定義書・PRD・旧資料をPDF/Word/Excelのまま投入し て読む 曖昧・矛盾・前提不足を質問リスト化。ここで人が意思決定す る 上位設計と詳細設計を分けて生成。非機能・移行方針も章立 てに含める 04 05 06 チケットに分解 実装へ引き渡す レポーティング Jira / Linearへ起票。ストーリーの重複は統合してから流す 同じ文脈のまま実装セッションへ。設計判断の根拠が残る 経営・非開発者向けにWord/PDFへ。コードを載せない機能 設計書も可 Devinだからこそ：要求定義を「文章として要約」するのではなく、対象リポジトリの実装制約と照らして矛盾を指摘できる。米大手金融では、要求定義到着をトリガに自動でレビューを走ら せる運用まで到達している。 Proprietary & Confidential 15
16. PATTERN B｜上流 型② 要件定義書のレビューを規約どおりに自動化する 上流の実務は「作る」より「直す・確かめる」に時間が寄る。 Devin Reviewがナレッジに書いた御社のレビュー規約で一次審査し、指摘コメントを付与する。 デモ：ナレッジで規約を書き、PRで一次レビューを回す 上流成果物に対する3つの働き方 ナレッジに書いたレビュー観点の例 作成 ゼロから起こす 既存コード・旧資料からリバース生成。画面／帳票／機能単位で並列に量産 文書メタデータ（管理番号、版数、レビュアー）の必須項目 必須章立ての有無と順序 「適切に」「高速に」といった曖昧な表現の検出 API仕様・セキュリティ（個人情報の取り扱い）の記載漏れ 改訂 変更に追従させる 設計方針の変更を全章に波及。採用しなかった代替案とその理由まで追記 仕様書のPR 規約で審査 PRに指摘 Auto-Fix 機械的に直せる指摘はAuto-Fixが修正まで行い、人は判断が必要な箇所に集中できる。規約を差し替えれば御社 基準の一次レビューになる。 レビュー 正しさを検証する 観点を整理してNG件数付きで報告。整合性チェックはCIに組み込む デモ資料（クリックで開く） REVIEW.md（レビュー規約の設定ファイル） レビュー対象PR #6（仕様書変更への指摘コメント） Devin Review画面（PR #6のレビュー結果） Proprietary & Confidential 16
17. PATTERN C｜上流 型③ 既存システムからのモダナイゼーション パート 1 で現行システムの資産をGit に出して文書化し、パート2 でサブシステム単位に検証を伴う移行を回す パート 1 現行資産の取り出しと文書化 P1.01 P1.02 P1.03 P1.04 ソースを Git へ抽出 DeepWiki で資産理解 運用知識をナレッジ化 ソース、画面定義、ジョブ制御、メニュー、帳票定義 をサブシステム単位でGit へ出力。文字コード変 換とコメントの文字化けを最初に確認する。 リポジトリに DeepWiki を生成。モジュール構成、 呼出し関係、DB モデルが図になる。Ask Devin でモジュール横断の質問に答えられる状態にす る。 ジョブスケジュール、運用手順、命名規約、移行先 の設計方針を Knowledge に登録。コードに無い 情報はここで補う。 仕様書と ビジネスルールID を作 成 P2.01 P2.02 P2.03 P2.04 対象と方式の判定 移行先言語で実装と PR 照合と現行システム比較 レビューと切替 サブシステムごとに、パッケージ採用、移行先言語 での作り直し、11 移行を判定。11 移行は自己完 結したプログラム群から始め、アーキテクチャ刷新 は同時に行わない。 Devin が隔離 VM 上で移行先の実装、BRID 対 応表、テストを作成しPR を提出。1 プログラム = 1 モジュール (クラス) を原則にする。 仕様書と実装の全項目照合、単体テスト全件実 行、現行システムと同一シナリオでの出力比較。差 分は Devin が修正して再提出する。 顧客チームが全 PR をレビュー (必須)。承認後に データ移行、バッチ、帳票の切替を個別ワークスト リームとして進め、移行済み一覧を更新する。 パート 2 プログラム別仕様書、業務ルール一覧、データ辞 書、不明点リストをDevin が作成。顧客有識者が 移行前にレビューし、解釈差を確定する。 検証を伴う移行 Proprietary & Confidential 17
18. PATTERN D｜隣接領域 型④ 要件定義書・設計書を最新の状態に保ち続ける 工程としては実装以降だが、上流成果物が使い続けられるかを決めるのはここ。 Devinは「書く人」ではなく「最新に保つ仕組み」として置ける。 TRIGGER SCHEDULE PLAYBOOK 実装マージを検知して追従 定期実行で乖離を検出 全体仕様書を定期更新 実装リポジトリの変更を起点に、仕様リポジトリ へ差分反映 PRを自動生成。 設計書とコードの乖離を週次で検出し、整合性 レポートとして提出。 章立て・粒度を Playbookで固定し、スケジュー ル実行で更新案を出す。 この仕組みで機械的に確かめられること 設計書 ⇔ ソース 設計書 ⇔ 旧資料 設計書 ⇔ 実際の応答 週次で定点観測 記述と実装の乖離を検出。画面・機能単位で並 列に回す 旧Excel設計書と突合し、記載漏れやテスト観点 の不足を洗い出す APIのJSONレスポンスとスキーマ定義を照合 し、仕様との差を確認 整合性レポートを定期生成し、乖離の発生を早 期に見つける Devinだからこそ：人が起動しなくても動き、指摘には行番号・スキーマ・件数が付く。 Confluenceや社内Wikiを直接更新する運用もあり、「ドキュメント整備プロジェクト」を常時稼働のプロセスに置き 換えられる。 Proprietary & Confidential 18
19. FORMATS 対応フォーマット：現在のワークフローに幅広く対応 既存の様式やツールを変えずに導入できる。Markdownで正典を持つ運用にも、既存様式のExcelやWordでの入出力にも対応する。 Markdown (.md) リポジトリ内の正典 要件定義書・設計書・テスト仕様書の主形式。Gitで差分レビューできる。ExcelからMDへの移行例もある。 Excel (.xlsx) 既存SI様式のまま 画面設計書・マッピング仕様書・レビュー結果表。.xlsxをGitに置き、セル単位で改訂PRを出す運用も。 Word (.docx) 読ませるための成果物 機能設計書の出力、既存様式への記入、Word要件書の取り込み。「コードを載せない設計書」の要望に対応。 PDF 入力と最終形の両方 PRDや図面をPDFのまま読ませてレビュー。帳票仕様書をPDFで納品する例も。 Confluence / Wiki 格納先を直接更新 定期実行でページを更新、または更新案を提示。ドキュメントの置き場所を変えずに導入できる。 CSV・図（Mermaid等） 指摘一覧と図表 仕様誤りの一覧化、設計書内のフロー図・構成図の生成。 注：フォーマットの傾向は PRタイトル・セッションタイトルからの集計。添付ファイル実体の全数検証ではない。 Proprietary & Confidential 19
20. LIVE DEMO｜ACAS（COBOL） COBOL業務システムにおける、仕様の再構築から移行まで 題材はCOBOLで書かれた業務システム（ACAS）。仕様書がない状態から現行仕様を起こし、業務要件まで踏み込み、 Python REST API＋Reactへ移行し、以後の仕様更新を自動で回すとこ ろ までを1本の流れで実演する。 01 02 03 04 05 現行仕様を抽出する 業務要件を抽出・推定 並列でマイグレーションする 新しい仕様を作る 更新を自動で回す DeepWikiでコードベース全体を索引 し、Playbook !spec_from_code で 現行仕様書を出典付きで生成する !biz_req にマニュアル等の追加資料 を投入し、コードに現れない業務意味 づけを含む業務用件定義書を抽出・ 推定 @madmerger/ACAS をPython REST APIバックエンドとReact フロン トエンドにマイグレ。仕様書 （DeepWiki）との整合性を確認しなが !spec_from_codeで、新しいレポジト リーの仕様を作成。成果物は @madmerger/ACAS-python-react にPR。 以後PRマージの度に仕様が更新さ れ、最新のコード一致するように !spec_update をAutomationに設定 らできるだけ並列で実行。インター フェースを全て日本語化。 この流れで確かめられること 仕様書がなくても、現行の挙動を根拠付きで文書化できる 廃止判断・データ移行・受入基準・並行稼働の判断材料が揃う 使うもの DeepWiki / Ask Devin 索引済みの現行コードに、出典付きで問い合わせる Playbook !spec_from_code ／ !biz_req ／ !spec_update で 様式を固定する Session（並列） バックエンドとフロントエンドを別セッションで同時に 進める Devin Review ＋ Automation 生成した仕様書の一次レビューと、以後の更新を自 動実行する 移行の計画と実装を、仕様書と突き合わせながら並列で進められる 移行後は仕様が置き去りにならず、更新が工程として残る Proprietary & Confidential 20
21. 2026 Q&A
22. WHY DEVIN Why Devin：上流工程で効くのは、常時の索引と自走する運用 コードを読めるかどうかの差ではない。差が出るのは、既存システムを継続的に索引しているか、人の着手を待たずに工程として回るか、成果物が組織の資産として残るか。 クラウド方自律エージェント＝ Devin ローカル型対話エージェント 依頼のたびに対象を読み込む。文脈は各自の手元に残る Deep Wikiが対象リポジトリを継続的に索引し、構成・依存・経緯を地図として保持。 調査の起点にできる 指定した範囲の調査は得意。全体の棚卸しは人が範囲を切る 現行機能一覧の再構築、 DB・IF棚卸し、影響範囲の洗い出しを、実行環境で動かして確 かめながら進める 開発者の端末で動く。環境は各自のローカルに依存 クラウド上の隔離環境で自分でビルド・実行・ DB参照。記述をソースと実物で突き合わせ られる 人が同時に走らせる本数の範囲 子セッションで画面 ID・帳票・工程単位に分割。上流工程セッションの約 3割が子セッショ ン 人がターミナルで起動する前提 PRマージ・スケジュール・ API・チケット起票から起動。 Slack／Jira／Linearから工程に組 み込める 手元のファイルとして生成。規約は各自の設定 Devin ReviewがREVIEW.mdの組織規約で PRを一次審査。 Office形式・Confluenceも成 果物として扱える 既存コードの把握 As-Is調査 実行環境 並列実行 起動経路 レビューと成果物 As-Is 注：Claude Codeもコードを読み解ける。ここで比べているのは運用モデル（索引の持続性、実行環境、起動経路、組織への資産化）の違い。 Proprietary & Confidential 22