はじめに こんにちは。リテールハブ小売アプリ開発チームの池です。 小売アプリチームでは、昨年から CodeRabbit を利用して PR レビューを行っています。日々活用してはいるものの、アップデートの内容を追いきれていませんでした。そこで本記事では、2026 年にアップデートされた内容を整理し、気になった機能をピックアップして紹介します。 なお、本記事の内容は 2026 年 8 月 12 日時点の情報をもとにしています。CodeRabbit はアップデートの頻度が高いため、機能の挙動やプラン要件は変わっている可能性があります。最新の情報は公式ドキュメントをご確認ください。 また、私たちのチームでは Pro プランを利用しているため、Pro プランで利用できる範囲を中心に、Pro+ プラン限定の機能はその旨を明記しながら紹介します。 2026 年アップデートの全体像 CodeRabbit の Changelog および 公式ドキュメント をもとにアップデートの全体像を整理します。2026 年 1〜8 月の changelog は約 100 件あり、主なアップデート内容を独自に抜粋して整理すると次のようになります。 カテゴライズ 主なアップデート（月） 概要 レビューUX ・Multi-Repo Analysis（2 月、6 月拡充） ・Review auto-pause（2 月） ・Slop PR 検出（3 月） ・Quiet プロファイル（7 月） マルチリポ分析の登場とレビューノイズの削減 Finishing Touches ・Autofix（2 月） ・Simplify（3 月） ・Resolve Merge Conflicts（3 月） ・Custom Recipes（3 月） ・Fix CI（7 月） レビュー後の修正作業をエージェントに委譲 CLI・コーディングエージェント連携 ・Claude Code Plugin（2 月） ・CodeRabbit Skills（2 月） ・CLI --agent モード（3 月） ・Codex plugin（4 月） Claude Code などのコーディングエージェントにレビューを統合 静的解析ツールの追加 ・Trivy / TFLint（2 月） ・zizmor（5 月） ・oasdiff（6 月） ・ast-grep の Dart 対応（6 月） ・e18e（7 月） 対応言語・領域の拡大（今年だけで 10 種超） Analytics・ダッシュボード ・Learnings ダッシュボード（2 月） ・ダッシュボード再編（3 月） ・利用メトリクス（6 月） ・レートリミット可視化（7 月） 運用状況の可視化が大幅に強化 外部ツール連携・CodeRabbit Agent ・Slack 向け Agent（4 月） ・メッセージトリガー自動化（4 月） ・Post-Merge Actions（7 月） ・Agent Skills（7 月） Slack を入口にした汎用エージェントと SaaS 接続の拡大 Plan ・Issue Planner（2 月） ・VS Code での Plan（6 月） Issue からの実装計画生成 セキュリティ ・Betterleaks（3 月） ・Security Agent（7 月） ・Secrets 検証ステータス（7 月） ・Git 履歴スキャン（7 月） PR レビューからコードベース全体のスキャンへ ナレッジ・Learnings ・承認フロー（6 月） ・Learnings API（6 月） ・Code Guidelines 管理 UI（6 月） 学習内容の可視化と統制 組織管理・ガバナンス ・Custom Roles（2 月） ・Audit Logs（3 月） ・Pro+ プラン導入（4 月） ・Global Overrides（4 月） エンタープライズ向け統制と料金体系の再編 Change Stack ・semantic diff / Code Peek（5 月） ・Change Stack 各プラットフォーム展開（5〜7 月） ・アプリ内レビュー会話（7 月） 意味的に構造化された PR レビュー専用UI と各プラットフォーム展開 ここからは、この中から気になった 5 つのテーマをピックアップして紹介します。 ① レビューUX 2 月: Multi-Repo Analysis が登場 3 月: Pro プランでリンク可能リポジトリ数が 1→2 に増加 6 月: レビュー対象 ref の固定（Multi-Repo Ref Selection）、自動リポジトリリンクとその管理 UI（Pro+ プラン） Multi-Repo Analysis は、PR のレビュー時に関連リポジトリのコードも合わせて参照して分析する機能です。単一リポジトリの diff だけでは見つけられない、リポジトリをまたぐ問題（API の破壊的変更、型の不一致、依存のドリフトなど）を検出できます。たとえばモバイルアプリと API サーバーが別リポジトリに分かれている場合、サーバー側の API 変更に対して「アプリ側の呼び出しが壊れないか」という観点をレビューに加えられます。 Pro プランでは自動リンク機能が使えないので、管理画面から手動で関連するリポジトリを設定しないと本機能は適用されないようです。設定方法を見ていきます。 設定方法 リンク設定は、管理画面の Review > Repositories > Settings > Knowledge base にあります。手動でのリンクと自動リンクの 2 通りがあります。なお、リンクできるリポジトリ数について、changelog には 3 月に Pro プランで 1→2 に増加したと記載がありますが、執筆時点の管理画面では 1 リポジトリまででした。 手動でリンクする リポジトリ設定はデフォルトで Organization 設定を継承しており、この状態ではリポジトリ単位のカスタマイズができません。Review > Repositories > Settings > General にある「Use Organization Settings」のトグルを一度クリックすると、設定の継承は on のまま、リポジトリ単位で編集できるようになります。 Linked repositories でリンクするリポジトリを選択し、Instruction にリポジトリ間の関係を記述できます。 保存すると Linked repositories の一覧に表示され、リンク設定は完了です。 自動リンク（Automatic repository linking） Automatic repository linking を有効にすると、Organization 内の関連するリポジトリが自動的に検出されリンクされます。なお、自動リンクは Pro+ プラン以上の機能です。 Multi-Repo Analysis のレビューでの見え方 Multi-Repo Analysis の結果は、PR Walkthrough の Review details > Additional context used に、リンクされたリポジトリ名ごとにグループ化されて表示されます。自動リンクされたリポジトリが含まれる場合は、Review info セクションに CodeRabbit が参照したリポジトリの一覧が表示され、それぞれに手動リンクか自動検出かのラベルが付きます。また、関連がある場合はインラインのレビューコメントやコメント返信にも指摘として現れます。 なお、Review details セクションを表示するには、 .coderabbit.yaml で review_details を有効にしておく必要があります。 # .coderabbit.yaml reviews : review_details : true ② Finishing Touches Finishing Touches は、レビュー後の仕上げ作業（指摘の修正、docstring や単体テストの作成など）を、PR コメントや PR Walkthrough のチェックボックスから CodeRabbit のエージェントに任せられる機能群です。 2 月: Autofix（未解決の指摘への修正を自動適用）、Chat code editing（Early Access） 3 月: Simplify、Resolve Merge Conflicts、Custom Recipes 7 月: Fix CI（CI 失敗の調査から修正・PR 作成までを行う） Finishing Touches の一覧 執筆時点で利用できる Finishing Touches は以下の 7 種類です。一部は Pro+ プラン限定となっています。 Autofix（指摘の自動修正） Docstrings（docstring の生成） Fix CI（CI 失敗の修正、Pro+ プラン） Resolve Merge Conflicts（コンフリクトの解決、Pro+ プラン） Unit Tests（単体テストの生成、Pro+ プラン） Simplify（コードの簡素化、Pro+ プラン） Custom Recipes（カスタム定義による修正、Pro+ プラン） トリガー方法は 2 種類あります。 PR コメント: @coderabbitai generate docstrings のようなコメントを投稿する チェックボックス: PR Walkthrough のコメント上のチェックボックスにチェックを入れる Autofix Autofix は、PR に残っている未解決のレビュー指摘を対象に、サンドボックス内で修正を作成する機能です。修正の反映先は、現在のブランチへの直接コミットか、stacked PR かを選べます。 以下のようにコメントすることで利用できます。 @coderabbitai autofix # 修正を現在のブランチにコミット @coderabbitai autofix stacked pr # 修正を stacked PR として作成 Autofix 機能はデフォルトで有効になっています。リポジトリ単位で無効にしたい場合は、 .coderabbit.yaml で設定します。 # .coderabbit.yaml reviews : finishing_touches : autofix : enabled : false # Autofix を無効化 実際に試したところ、人間のレビュアーのコメントに対して @coderabbitai autofix stacked pr を実行しても、以下のようにスキップされました。 Autofix の対象は、CodeRabbit 自身が投稿した修正手順つきの未解決レビューコメントのみで、人によるレビューコメントの修正は任せられないようです。 次に、CodeRabbit の修正手順つき未解決コメントが残っている PR で実行したところ、今回は受け付けられました。特定の 1 件の指摘スレッドへの返信として実行しましたが、PR 上の未解決指摘 17 件すべてが修正対象になりました。コメントを投稿した場所に関係なく、PR 単位で一括適用される挙動のようです。 実行から約 6 分半で、12 ファイルの修正を含む stacked PR が作成されました。 ③ CLI・コーディングエージェント連携 CodeRabbit CLI は、ターミナルから手元のコード変更に対して CodeRabbit のレビューを実行できるツールです。PR を作成する前に、ローカルで指摘の検出と修正を済ませられます。2026 年は、この CLI を土台にした Claude Code などのコーディングエージェントとの統合が進みました。 2 月: Claude Code Plugin 対応、CodeRabbit Skills（open agent skills 標準） 3 月: CLI --agent モード（構造化 JSON 出力）、CLI 用 Usage-based アドオン（従量課金オプション） 4 月: CLI ブラウザ完結のサインイン、Codex plugin 対応 5〜8 月: coderabbit doctor 、 --light モード、レビュー信頼性の改善 CLI は無料プランでも利用できます（基本的な静的解析、1 時間あたり 3 回まで）。Pro プランにすることで、組織の Learnings を活用した強化レビューになり、レートリミットは 1 時間あたり 5 回に引き上げられます。 コーディングエージェントに CLI を統合するメリット CodeRabbit は、Claude Code などのコーディングエージェントと CLI を組み合わせる意義を、次のような役割分担として説明しています。 専門家による問題検出 : 一般的なリンターでは見逃しやすい競合状態・メモリリーク・論理エラーを CodeRabbit が検出する AI を活用した修正 : Claude Code が CodeRabbit の分析結果に基づいて修正を実装する コンテキストの保持 : 問題の発生場所・深刻度・推奨される対処法が簡潔に Claude Code へ渡される 継続的なワークフロー : ツールを切り替えることなく、レビュー → 修正 → 反復のループを開発の流れの中で回せる Claude Code への導入方法 導入は「CLI のインストール・認証」と「Claude Code へのプラグイン追加」の 2 段階です。 まず CodeRabbit CLI をインストールします。 curl -fsSL https://cli.coderabbit.ai/install.sh | sh # または brew install coderabbit 次に認証を行います。4 月の CLI v0.4.0 からサインインはブラウザで完結するようになりました。 coderabbit auth login Claude Code 側では、公式プラグインマーケットプレイスに CodeRabbit が用意されているので、選択するだけで使えるようになります。 プラグインの内容 導入すると、Claude Code 内で coderabbit-review コマンドと、code-review・autofix の 2 つのスキルが利用できるようになります。 /coderabbit:coderabbit-review : 手元の変更に対して CodeRabbit のレビューを 1 回実行し、結果を表示するコマンド /coderabbit:code-review : CodeRabbit のレビューをワークフローとして扱うスキル。エージェントがレビューを必要と判断した場面でも自動起動する /coderabbit:autofix : GitHub PR のレビュースレッドにある CodeRabbit の指摘を、変更ごとに承認を挟みながら安全に適用する また、プラグインとは別に、open agent skills 標準に対応した CodeRabbit Skills も提供されています。Claude Code の場合はプラグインの導入でスキルも一緒に入るため追加の作業は不要ですが、Cursor / Codex / Gemini CLI など他のエージェントでも使いたい場合は、以下のコマンドで各エージェントのスキルディレクトリに導入できます。 coderabbit skills code-review と autofix の 2 つのスキルの実体は、ワークフローを記述した Markdown ファイル（SKILL.md）です。それぞれ次の内容がワークフローとして明記されています。 code-review : 「実装 → レビュー → Critical/Warning の修正 → 再レビュー → クリーンになるまで繰り返す」という自律ループ autofix : エージェント自身が指摘の妥当性をローカルコードで検証し、1 件ずつユーザーの承認を取りながら修正を適用する手順 ループが前提として設計されている点、必要な箇所で人の承認を挟んでいる点から、AI を使った開発ワークフローに CodeRabbit を自然に組み込める仕組みだと感じました。 ④ 静的解析ツールの追加 静的解析ツールの追加は活発に行われており、1〜8 月だけで 10 種を超えるツールが追加・更新されています。対応しているツールの一覧は 公式ドキュメントの Tools 一覧 を参照してください。 2 月: Trivy（IaC のセキュリティスキャン）、TFLint（Terraform）、Stylelint（スタイルシート）、TruffleHog（シークレットスキャン）、OpenGrep（Semgrep 互換の静的解析エンジン）など 9 種 3 月: Betterleaks（シークレットスキャナを Gitleaks から Betterleaks へ置き換え。既存の gitleaks 設定キーがそのまま使える） 5 月: zizmor（GitHub Actions ワークフローのセキュリティ解析） 6 月: Infer（C / C++ / Java の null 参照・リソースリーク・並行処理バグ検出）、oasdiff（OpenAPI の破壊的変更検出）、React Doctor（React のセキュリティ・パフォーマンス・アクセシビリティの問題を検出）、ast-grep の対応ファイルタイプ拡大（Dart、TOML、Markdown など） 7 月: e18e ESLint plugin（モダンな代替がある依存や、メンテナンスされていないパッケージを指摘） これらの静的解析ツールは CodeRabbit ではほぼすべてデフォルトで有効になっており、該当するファイルタイプの変更を検出すると自動で実行されます。 ルールの詳細を制御したい場合は、各ツールの設定ファイルを使います。リポジトリに .eslintrc.js や pyproject.toml があれば CodeRabbit はそれを尊重するため、既存の設定をそのまま生かせます。 また、対象領域は、シークレット・IaC・CI 設定といったアプリケーションコードの周辺へと拡大しています。PR レビューの対象が、コードそのものからリポジトリ全体の安全性へ広がっていると感じました。 複数のリポジトリを運用していると、リポジトリごとに静的解析ツールを選定して管理していくのはそれなりのコストになります。ツールの追加・実行・アップデートを CodeRabbit 側が担ってくれることで、この導入・運用コストを下げられるのはメリットの一つだと思いました。 ⑤ Analytics Analytics は、CodeRabbit の管理画面で組織のレビュー活動を可視化するダッシュボード機能です。レビューされた PR の数や指摘への対応状況、レビューにかかった時間、Learnings などナレッジの活用状況といったメトリクスを、リポジトリ・ユーザー・期間で絞り込みながら確認できます。 2 月: Learnings ダッシュボード（KPI カード、利用回数・最終利用日などのメタデータ） 3 月: ダッシュボード再編（Git プラットフォームレビューと IDE/CLI レビューの分離、Knowledge Base / Pre-merge Checks / Reporting などの新ページ） 6 月: Path 指示・Finishing Touches の利用メトリクス 7 月: レートリミット影響の可視化（Usage Rate-Limit Insights）、Explore ページのレコメンデーション 3 月の再編により、Analytics は大きく「PR reviews」と「IDE/CLI reviews」の 2 つに分かれています。それぞれ見ていきます。 PR レビューのメトリクス PR レビュー側は Summary / Quality Metrics / Time Metrics / Knowledge Base / Organization Trends / Pre-merge Checks / Reporting / Data Metrics のページで構成されており、すべては書ききれないほど多くのメトリクスがあります。以下は Summary ページの画面です。 ここでは代表的な項目を挙げます。 レビュー成果 : レビュー済みでマージされた PR 数、投稿コメント数、Acceptance Rate（開発者が指摘に対応した割合）、Reviewer Time Saved（AI 推定のレビュー工数削減時間） 時間系 : レビュー可能になってから「マージ」「最初の人間レビュー」などまでの時間（平均・中央値・P75・P90）と週次トレンド ナレッジ系 : Learnings の作成数・適用率、Path-based Instructions の利用率、MCP サーバー別の PR カバレッジ 運用系 : Pre-merge Checks や Finishing Touches の実行数と結果、レートリミットの影響 これらのメトリクスは、開発プロセスの改善、効果の定量的な説明、CodeRabbit 自体のチューニングなど、幅広く活用できそうです。 IDE/CLI レビューのメトリクス IDE / CLI がチームでどれだけ使われているかを示すメトリクスです。 アクティブユーザー数・レビュー数・レビューコメント数を、IDE 拡張 / CLI の種別ごとに集計 Learnings や Path-based Instructions がローカルレビューに適用された割合 SAST・リンターによるツール検出の内訳（ツール別・重要度別） ユーザー別の明細（拡張の種別、導入日、最終利用日時、レビュー数） 従来見えづらかった PR に到達する前の品質活動を追えるのは、開発フローの改善を測るうえで示唆がありそうです。 おわりに 本記事では、CodeRabbit の 2026 年 1〜8 月のアップデートを整理し、気になった 5 つのテーマをピックアップして紹介しました。 アップデートの内容を追うと、CodeRabbit が PR レビューのツールにとどまらず、開発ライフサイクル全体を支えるエージェントプラットフォームへと広がっていると感じました。 AI によりコードの生成量が増大する中で、いかに効率良く品質を担保するかは、AI 活用における課題の一つだと思います。CodeRabbit を適切に活用することは、この課題を解決する方法の一つになると感じています。 私たちのチームでも、今回整理したアップデート内容を実際の開発フローに組み込みながら、活用を広げていければと思います。 本記事が少しでも参考になれば幸いです。最後まで読んでいただきありがとうございました。

2026 年 7 月 16 日（木）、 17 日（金）の 2 日間、東京・麻布台ヒルズにて、ISV SaaS 事業者向けの 8 社合同 AI-DLC Unicorn Gym を開催しました。株式会社サイバーセキュリティクラウド、freee 株式会社、株式会社いえらぶ GROUP、モビルス株式会社、エムオーテックス株式会社、株式会社ヌーラボ、テクマトリックス株式会社、株式会社ヴァル研究所（順不同・敬称略）の 8 社から計 54 名にご参加いただき、各チームが自社プロダクトの開発テーマを持ち込んで、Kiro や Claude Code などの Coding Agent を活用しながら 2 日間 AI 駆動の開発プロセスを実践しました。 本記事では、ご参加いただいた各社が 2 日間 AI-DLC をどう体験したのか、参加者の声を交えてレポートします。 AI-DLC (AI-Driven Development Lifecycle) とは AI 駆動開発ライフサイクル（AI-DLC）は、AWS が提唱する、AI を開発プロセスの中心に据えた開発手法です。AI を単なるアシスタントとして使うのではなく、要件定義・設計・実装の主役を AI が担い、人間は「何を作るか」「その出力は正しいか」という意図のすり合わせと重要な判断に集中します。この役割分担により、従来は数ヶ月かかっていた要件定義から実装までの期間を数日に圧縮することを目指します。 AI-DLC の開発プロセスは Inception・Construction・Operations の 3 フェーズで構成されます。鍵となるのが、チーム全員で 1 つの画面を囲み、AI と対話しながら進める「モブワーク」というスタイルです。一人が操作役（ドライバー）となって手を動かし、残りのメンバー全員がその場で意見を出し合い、議論しながら進めます。Inception を全員で行うフェーズを「モブエラボレーション」、Construction をサブチームに分かれて進めるフェーズを「モブコンストラクション」と呼び、いずれもこのモブワークを基本形とします。AI が要件を整理し、選択肢やコードを素早く提示し、ビジネス・開発メンバーがその場で検証・判断する。この共同作業が、開発速度の向上だけでなく、ビジネスと開発のギャップを埋め、チーム全員の認識を揃える効果をもたらします。 AI-DLC の詳細については、 AI 駆動開発ライフサイクル：ソフトウェアエンジニアリングの再構築 をご参照ください。 AI-DLC Unicorn Gym 開催の背景と ISV SaaS 8 社が持ち込んだテーマ AI-DLC Unicorn Gym は、AI-DLC を座学ではなく自社の実テーマで実践していただくプログラムです。各チームが実際の開発テーマを持ち込み、AI と対話しながらユーザーストーリーの作成から実装、成果発表までを 2 日間で走り切ることで、AI 駆動の開発プロセスによる効果を体感していただきます。 今回の AI-DLC Unicorn Gym は、ISV SaaS 事業者を対象とした複数社合同の形式で開催しました。AI-DLC Unicorn Gym 開催のご要望を多くいただいておりますが、複数日にわたって数十名の参加者を集めることがハードルとなり実施を断念されるケースもありました。複数社合同とすることで、各社 1 チームからの参加を可能にしました。 参加各社には、練習用の題材ではなく「自社の実際のプロダクト開発テーマ」をご用意いただきました。テーマは、既存プロダクトへの新機能追加、既存ページのリニューアル・モダナイズ、新規プロダクトの立ち上げ、業務プロセスの改善支援など多岐にわたりました。 2 日間のスケジュール 本イベントは、初日に Inception、2 日目に Construction を中心に据えた 2 日間の構成で実施しました。各日ともチーム全員が 1 つの画面を囲むモブ形式で進め、初日の終わりに中間報告会、2 日目の終わりに最終報告会を設けています。タイムスケジュールは目安であり、各チームの進捗状況に合わせて進めていただきました。 今回は AI-DLC の進行には Coding Agent 用のルールセットである aidlc-workflows をご利用いただきました。aidlc-workflows v2 が 7月に GA しましたので、詳しく知りたい方は AI-DLC Workflows 2.0 のご紹介 および AI-DLC Workflow V1からV2へ：人間のボトルネックを解消する設計の進化 をご確認ください。 Day 1 9:30　キックオフ / AI-DLC Introduction 10:00　aidlc-workflows EC サイト構築ハンズオン 11:30　昼食 12:30　Mob Elaboration（Inception）: 開発対象のスコープやユーザーストーリー、作業単位の精緻化 17:15　中間報告会（1 日目の進捗状況を共有） Day 2 9:30　Mob Elaboration / Mob Construction :ドメインモデル設計、アーキテクチャコンポーネントの追加、プログラムやテストの作成 11:30　昼食 12:30　Mob Construction（各チームの進捗に応じて） 17:00　最終報告会（成果・学びの共有） 18:00　懇親会 Day 1: Inception 初日の午後から、各チームが自分たちのテーマをユーザーストーリーへ分解する「モブエラボレーション」に取り組みました。チーム全員が 1 つの画面を囲み、AI と対話しながら要件を詳細化します。ビジネスメンバーも開発メンバーも同じ場で AI の提案を検証し、判断し、修正していきます。このプロセスを通じてチーム全員のコンテキストが揃い、その共通認識が Construction フェーズにそのまま引き継がれます。AWS からは、「5 分以上 AI を遊ばせない」、「HTML/CSS でモックを作りチームのイメージを合わせる」、「How に関する議論は Construction まで我慢する」などのガイドを提供しました。 複数のチームから、 「仕様を決める速さで AI-DLC の力を実感した」 「圧倒的に早いスピード感で一定動くものを作れたのは大きな発見」 といった、要件定義のスピード向上に関する感想をいただきました。 株式会社いえらぶ GROUP の開発風景 Day 2: Construction 2 日目は、並行して実装できるサブチームに分かれて Construction を進め、最終報告会へ臨みます。AI が高速にコードを生成するなか、参加者はその方向性が適切かを検証・判断しました。 2 日間という短い時間ながら、8 チーム中 6 社がデモ可能な状態まで実装を完了しました。設計フェーズでの AI 活用に対して、 設計での AI という使い方で、よくできたフレームワーク。次回の新機能開発はこれで実施する。 といった手応えを語るチームもありました。 最終発表会では、「従来 1 ヶ月以上かかっていた要件定義フェーズが2日間で完了した」、「ジュニアメンバーが AI との対話を通じてドメイン知識へのキャッチアップを実現した」、といった成果の共有がおこなわれました。 参加者からのフィードバック 今回は参加者の方には AWS オフィスにお集まりいただき、各社様担当の営業メンバー・ソリューションアーキテクトがサポートをさせていただきました。モブワークという形式について、いくつものフィードバックをいただきました。 我々のチームのことをよく知るサポーターが、過度でもなく過小でもなく、適切なタイミングで声掛けしてもらえた 普段リモートワークなので、オフラインで一緒に開発できてよかった。フレームワークのおかげで会話が整理された。 また、ドキュメント作成やコーディングを高速にこなす AI に対して高頻度で意思決定・判断が求められることについて、 判断負荷が高いので、普段の業務時間だと後回しにしてしまいそう。集中して向き合えてよかった という感想もいただきました。モデルの進歩により AI の自律性が高まる中、どこまでを人間が判断し、どこまでを AI に委ねるかはまさに今注目されている観点です。 イベント後のアンケートでは、80 % の参加者から最高点の ︎5 評価をいただきました。「AI-DLC はあなたの働き方を変える可能性があるか」という問いに対しても平均 4.76 / 5.0 というご回答をいただきました。また平均工数削減率は 67.1%と、これまでの 3 倍の速度を実現できると体感していただきました。 おわりに AI がコードを書いてくれるようになると、人間の仕事は「書くこと」から「決めること」へと移っていきます。何を作るか (あるいは作らないか) を決めること、設計の方向性を判断すること、チーム間の認識を揃えること。AI-DLC がモブワークを重視するのは、この意思決定に集中できる環境を作るためです。 自社で AI-DLC を試してみたいという方は、まず aidlc-workflows をお試しください。Kiro や Claude Code などを使って AI-DLC を始めるためのワークフローやテンプレートが公開されています。AI-DLC は特定のツール・ワークフローに依存しない方法論です。皆様のこれまでの開発プロセスや組織構造、スキルセットなどによってカスタマイズして取り入れていただくことができます。 自社プロダクトを持つ ISV/SaaS 事業者にとって、AI-DLC はプロダクトの開発サイクルそのものを変えうる手法です。合同開催が「終わり」ではなく、それぞれの現場での「始まり」として受け止めていただき、この 2 日間の体験を各社の現場に持ち帰り、それぞれの形で活かしていただけることを楽しみにしています。 これまでの合同型 AI-DLC Unicorn Gym については以下のブログ記事もご覧ください。 11 社合同 AI-DLC Unicorn Gym で体験した開発のパラダイムシフト 9 社合同 AI-DLC Unicorn Gym 大阪 ── AI と開発した 3 日間で見えた、人間の仕事 9 社合同 AI-DLC Unicorn Gym：AI と作った 2 日間で見えた、 「書く」から「決める」への転換 筆者について 山崎 宏紀 (Hiroki Yamazaki) 山崎宏紀 は Amazon Web Services Japan G.K. のソリューションアーキテクトとして、ISV/SaaS 業界のお客様を中心にアーキテクチャ設計や構築、生成 AI の活用・AI エージェントの開発をご支援しています。Kiro CLI や AWS CDK を好みます。(より良いご支援のために) AI エージェントに代わりに働いてもらおうと画策しています。

こちらの記事は「MEDLEY Summer Tech Blog Relay」の20日目の記事です。 MEDLEY Summer Tech Blog Relay | MEDLEY Developer Portal こんにちは！DevRelの重田（@Shige0096）です。 メドレーでは夏企画として『MEDLEY Summer Tech Blog Relay』と題して、ブログリレーを開催します！ 7/13(月)〜8/21(金)まで毎日異なるメンバーが... developer.medley.jp はじめに メドレー 医療プラットフォーム開発室 SREグループに2026年4月に入社した柏木と申します。 これまでの経歴は以下のとおりです。 1社目: 人事給与系企業の子会社に入社し、パッケージソフトウェアの導入設定やビジネスチャットのAndroidアプリ開発などを担当 2社目: メール配信SaaSのインフラ構築から開発、レンタルサーバー事業のエンジニアなどを担当 3社目: メドレー 医療プラットフォーム開発室 SREグループ（現職） このような流れで幅広い技術領域の経験を積んできたエンジニアです。 本記事では、社内向けの業務Webアプリを短期間で開発した経験を通じて、「AIによってWebアプリ開発がどう変わったか」についてお伝えします。 メドレーでは生成AI利用のガイドラインが社内で展開されており、各部門の業務ではそのガイドラインに沿って利用をしています。 何を作ったのか この1〜2週間で、社内業務の運用に必要な一部機能を備えた社内向けWebアプリを開発しました。 なぜ作ったのか（背景） メドレーの医療プラットフォームでは、医療事業者向けに複数のSaaSプロダクトを提供しています。私は社内業務の運用改善にも関わっています。 対象となる管理データは、運用しながら改善を重ねてきました。今後さらに効率的かつ再現性高く管理するため、一部の作業では Claude も活用しながら、データを正規化して仕組みとして管理できる状態を目指すことにしました。こうした課題感から、今回の開発をスタートしました。 「Webアプリ作りが簡単になった」と感じた3つの瞬間 「単なるCRUDのWebアプリならAIを使わずとも簡単に作れるのでは?」と思われるかもしれません。しかし今回は、既存のExcel形式を踏襲したスプレッドシート風の入力画面に加え、コメント機能、バージョン管理、差分比較、さらには管理メニューでの組織ツリー管理など、それなりの規模のアプリケーションになっています。 このアプリを開発する中で、「Webアプリ作りが本当に簡単になった」と確信した瞬間が3回ありました。 1. インフラ構成と要件を少し伝えただけで形になったとき AIに伝えたのは、インフラ構成、使用言語、開発の流れだけでした。文字数にすると、本記事のここまでの文章よりも少ない分量です。 その程度のプロンプトでほぼ全機能のコードが完成したとき、「最小限の知識とプロンプトで、新しいものをゼロから作れる時代になった」と実感しました。 2. Playwrightにテストを任せて、デグレを自動で発見・修正してくれたとき スプレッドシート風の入力画面は、手作業でのテストに非常に手間がかかり、デグレ（意図しない機能の後退や不具合）を見つけるのが困難です。 そこで Playwright によるテストの追加をAIに依頼し、すべてのテストをパスする状態を作りました。すると、次の修正を入れた際にAIがデグレを発見し、自律的に修正まで完了させてくれたのです。 開発の中でもっとも地道で骨の折れる作業が不要になった瞬間でした。 3. MCP（Model Context Protocol）サーバーを活用したとき 一番驚いたのはここです。 初期データの整備では、 MCP（Model Context Protocol） サーバーの機能を追加し、Claude経由で「自然言語による処理内容の設計からシェルスクリプトの作成まで」を行いました。 これが成功したとき、「Webアプリは、データを保持する『箱』と『インターフェース』に過ぎなくなったのだ」と深く納得しました。 なお、AIにデータベースを直接操作させるのではなくシェルスクリプトを出力させたのは、処理内容をコードとして固定化し、実行前にレビューできるようにすることでリスクを抑えるためです。 まとめ 上記の3点を、開発サイクルとして表現すると次のような形です。 この開発サイクルを通して、「業務Webアプリは誰でも簡単に作れる時代になった」ということを実感しました。 この学びから、エンジニアとしての今後の向き合い方は2つあると考えています。 AIを使い倒して開発プロセスを「シフトレフト」するか、AIを圧倒的に上回る専門性を磨くか 自分が作るプロダクトには積極的にAI機能を組み込んでいく AIを機能として組み込んだプロダクト開発ができれば、SaaS企業が提供できる価値はまだまだ広がりますし、AI時代を生き抜くエンジニアになれるはずです。 またどこかで体験談や知見を共有できればと思いますので、ぜひメドレーのDeveloper Portalのフォローをお願いします。 We’re hiring メドレーでは、SREをはじめ「医療ヘルスケアの未来をつくる」ことに取り組むエンジニアを募集しています。ご興味をお持ちいただけましたら、ぜひご応募ください。 ※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。 メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp MEDLEY Summer Tech Blog Relay 21日目の記事は山本さんです！お楽しみに！！