aidlc-workflows

The Most Important AI Engineering Skill Is Saying No (AI-DLC, bolts, and autonomous agents) --- title: "The Most Important AI Engineering Skill Is Saying No (AI-DLC, bolts, and autonomous agents)" published: true description: "AI-DLC, bolts, and autonomous agents promise faster software delivery. But who owns the architecture when AI starts making the decisions?" tags: ai, softwareengineering, architecture, productivity --- AI can now propose an architecture, break requirements into tasks, write the implementation, generate tests, and prepare a deployment. And we are increasingly building entire development methodologies around that capability. AWS introduced the AI-Driven Development Lifecycle (AI-DLC), with concepts such as Units of Work, Bolts, Mob Elaboration, and Mob Construction. Frameworks such as specs.md bring similar ideas into tools like Claude Code. The promise is compelling: shorter development cycles, persistent context, specialized agents, and fewer manual handoffs. But after exploring these methodologies, I keep returning to a question that seems more important than how quickly AI can produce software: Who is actually making the engineering decisions? Not who approves the final pull request. Not who clicks "continue" when an agent requests permission. Who decides whether an architectural proposal makes sense in the first place? {% card %} My argument: The most valuable human contribution to AI-driven software development may be the ability to reject an AI proposal, establish constraints, demand alternatives, and stop execution. If developers lose that authority, human-in-the-loop becomes little more than a ceremonial approval process. {% endcard %} We are redesigning software development around AI For years, the software industry has experimented with methodologies intended to improve how teams deliver software. Waterfall emphasized sequential phases. Agile introduced iterative development and faster feedback. Scrum provided a framework for organizing complex work, while Kanban emphasized managing flow. Now we have AI-native development methodologies. AWS describes AI-DLC as a model in which AI creates plans, asks questions, proposes solutions, and executes work after human validation. Its lifecycle has three major phases: | Phase | AI responsibility | Human responsibility | |---|---|---| | Inception | Elaborate requirements and propose units | Validate business intent and scope | | Construction | Propose designs, generate code, and test | Make technical decisions and validate results | | Operations | Prepare infrastructure and operational changes | Provide oversight and authorize consequential actions | The methodology also introduces Bolts, short execution cycles generally measured in hours or days rather than weeks. The ambition is to reorganize the development lifecycle around AI's ability to generate and execute work rapidly. {% embed aws.amazon.com %} This is a legitimate direction to explore. But there is a subtle difference between accelerating software development and accelerating the production of software artifacts. An agent can produce five architectural alternatives in minutes. It cannot guarantee that any of them is appropriate for the organization, its operational constraints, or the business problem. That distinction becomes increasingly important as agents gain autonomy. A Bolt is not a substitute for engineering judgment Consider a traditional development team implementing a reservation management feature. A developer might spend time understanding the domain, inspecting existing services, discussing edge cases, and choosing an implementation strategy. With an AI-driven workflow, an agent may perform much of that investigation and propose an implementation plan. The team can then approve the plan and let the agent execute it. This sounds efficient. But consider what happens when the agent proposes an unnecessarily complicated solution. For example: > Introduce a Kafka topic to propagate reservation state changes, a Redis cache for availability lookups, and a new microservice responsible for reservation lifecycle management. It sounds like an architecture. It even sounds like a reasonably sophisticated one. But what if the system currently handles a few hundred reservations per day, uses a single PostgreSQL database, and has no demonstrated scaling problem? The correct engineering decision might be: No. We do not need any of that. We might need one additional endpoint, a transaction, a database constraint, and two integration tests. An AI agent can generate a technically coherent architecture that is nevertheless a poor engineering decision. The danger is not only incorrect code. It is unnecessary complexity delivered at extraordinary speed. {% card %} A successful Bolt should not be measured by how much work the agent completed. It should be measured by whether the team delivered a correct, maintainable increment that solves the intended problem. {% endcard %} Human-in-the-loop is not the same as human-in-control This distinction deserves more attention. Many AI workflows include human checkpoints. The agent presents a plan, and a developer approves or rejects it. That is useful, but insufficient. Imagine the following interaction: AI: I recommend introducing an event-driven architecture. Developer: Approved. AI: I will implement three services and their supporting infrastructure. Developer: Approved. AI: Implementation complete. All generated tests pass. Developer: Approved. There were three human checkpoints. Yet we have no evidence that meaningful engineering judgment occurred at any of them. Now consider a different interaction. AI: I recommend introducing an event-driven architecture. Developer: Why? What problem does it solve that our existing transactional design cannot? AI: It could improve decoupling and asynchronous processing. Developer: Show me three alternatives. Compare operational cost, consistency guarantees, failure recovery, and migration effort. Our team maintains this platform with limited infrastructure capacity. AI: A transactional implementation appears sufficient under those constraints. Developer: Proceed with that approach. Do not introduce new infrastructure. The second interaction may produce less code. It may also produce substantially better software. The developer was not merely validating output. The developer was actively shaping the solution. Human-in-the-loop describes participation. Human-in-control describes authority. They are not equivalent. The four powers developers must retain I believe every serious AI engineering workflow should explicitly preserve four human capabilities. 1. Reject a proposal Developers must be able to reject a design without having to provide a replacement implementation immediately. This matters because rejecting a bad abstraction is often easier than constructing a better one. An AI-generated design may be logically consistent but violate established architectural boundaries, introduce unnecessary dependencies, or optimize for a problem that does not exist. A useful rejection should identify the concern: > Reject this proposal. It introduces a new service without demonstrating a need for independent scaling, deployment, or domain ownership. That is an engineering decision. Not an obstacle to automation. 2. Establish constraints AI agents need boundaries. Not just coding conventions, but architectural and operational constraints. For example: architecture: new_microservices: prohibited database: postgresql messaging: existing_kafka_topics_only public_api_breaking_changes: prohibited reliability: retries_must_be_bounded: true idempotency_required_for_commands: true backward_compatibility: required delivery: unrelated_refactoring: prohibited integration_tests: required production_deployment: manual_approval This is an illustrative policy, not a native specs.md configuration file. The point is that constraints should be explicit, versioned, and testable wherever possible. A developer should not need to repeat the same architectural principles every time a new agent session begins. 3. Demand alternatives One of the most dangerous properties of AI-generated solutions is how persuasive they can appear. A complete design document with diagrams, tradeoff tables, and confident explanations can create the impression that the design space has already been explored. It may not have been. For consequential decisions, developers should ask: - What is the simplest viable alternative? - What can we implement using existing components? - Which assumptions would make this design inappropriate? - What are the operational and maintenance costs? - What would make us reverse this decision six months from now? These questions force the agent to explore the decision rather than simply defend its first proposal. 4. Stop execution Autonomy should have boundaries. An agent should stop when it encounters an unresolved architectural decision, a destructive operation, a security-sensitive change, or a conflict between requirements. Consider a database migration. The agent discovers that implementing a new feature requires modifying a heavily used table. It should not automatically choose a destructive migration merely because doing so would complete the task. It should surface the conflict. EXECUTION PAUSED Reason: The proposed schema change may break existing consumers. Options: A. Backward-compatible additive migration B. Versioned API and staged migration C. Redesign the feature to avoid the change Decision required: Authorized engineering owner Stopping is not failure. Stopping at the correct moment is a feature of a well-governed autonomous system. But who should make these decisions? Not every decision belongs to the same person. Product owners and business stakeholders should determine which outcomes matter. Domain experts should validate business rules. Developers and technical leads should own engineering decisions, including architecture, implementation constraints, reliability, and maintainability. Authorized operational owners should control production releases. AI can help each group evaluate alternatives and execute approved work. It should not silently inherit their authority. This is also where AI-DLC should be evaluated against established engineering practices. The Scrum Guide makes developers accountable for creating the Sprint Backlog, adapting their plan, and maintaining quality through the Definition of Done. AI-DLC changes the mechanics of planning and implementation, but it should not erase that accountability. There is a difference between delegating execution and delegating responsibility. What happens when agents start making architecture decisions? Imagine a team maintaining a mature backend platform. The system has accumulated years of architectural decisions, operational lessons, domain-specific exceptions, and integration constraints. An AI agent receives a request: > Implement real-time reporting for active alerts. The agent examines the existing implementation and proposes a separate Redis-backed endpoint for active alerts, while historical alerts remain in PostgreSQL. At first glance, the design may appear reasonable. But the engineering team knows that this introduces two sources of truth for reporting. Now every consumer needs to understand which endpoint to query, how to reconcile results, and what happens during synchronization failures. The developer may instead insist on a unified reporting model with explicitly defined state transitions. That decision requires understanding more than the immediate feature. It requires understanding the system's history, consistency requirements, and future maintenance burden. AI can help investigate those concerns. But it cannot automatically determine which organizational tradeoffs are acceptable. This is precisely where experienced engineering judgment becomes valuable. The problem with measuring AI development through speed AI-DLC introduces shorter execution cycles, and frameworks such as specs.md provide structured workflows for implementing them. But how should we evaluate whether these methodologies work? A common demonstration shows an agent producing a working application in a few hours or days. That is impressive. It is not sufficient evidence of long-term engineering effectiveness. I would be more interested in what happens after six months. Can another developer understand the architecture? Can the team safely introduce a new feature? Do the specifications still describe the implementation? Can a developer challenge an earlier decision without rebuilding half the platform? How much human effort is required to review and repair generated changes? And when something fails in production, can the team diagnose it without depending on the original agent's conversation history? Those questions are harder to demonstrate than a successful prototype. But they are closer to what professional software engineering actually requires. A useful evaluation should compare: | Metric | What it reveals | |---|---| | Acceptance-test success | Whether the implementation meets requirements | | Human review time | How much effort correctness requires | | Rework after implementation | Whether the initial solution was appropriate | | Architectural complexity | Whether unnecessary components were introduced | | Operational incidents | Whether the system remains reliable | | Cost per accepted change | Whether faster generation creates real efficiency | | Maintainability over time | Whether future engineers can safely evolve the system | Counting completed Bolts is not enough. Counting generated lines of code is even less useful. The meaningful unit of progress is not AI activity. It is validated software value. Are we accidentally reinventing Waterfall? There is another uncomfortable possibility. Spec-driven AI development often emphasizes generating requirements, architecture documents, implementation plans, tasks, and tests before or during execution. These artifacts can improve traceability and preserve context. But if teams begin treating AI-generated specifications as authoritative simply because they were approved, we risk recreating a familiar problem. The process becomes: 1. Generate extensive requirements. 2. Approve the requirements. 3. Generate the architecture. 4. Approve the architecture. 5. Generate the implementation. 6. Discover that the original assumptions were wrong. That is not automatically Agile because the implementation happened in short Bolts. Agility requires the ability to revise assumptions and respond to new information. A Bolt can be short while the overall process remains rigid. Conversely, a team can use AI-generated specifications effectively if those specifications remain open to challenge, revision, and even deletion. The value of a specification is not that it exists. It is that it helps the team make and revisit decisions. A better AI engineering workflow I would rather see teams organize AI-assisted development around explicit decision boundaries. Not every small change needs a complete architectural review. But not every change should run on autopilot either. Here is a practical model. | Change | AI autonomy | Human involvement | |---|---|---| | Documentation correction | High | Review output | | Small API enhancement | High within constraints | Validate contract and tests | | Internal refactoring | Moderate | Review behavior preservation | | Cross-service integration | Limited | Approve design and failure handling | | Data migration | Restricted | Approve migration and rollback | | Security-sensitive change | Restricted | Independent security review | | Production deployment | Policy-controlled | Authorized release decision | The important property is that autonomy is proportional to risk. An agent should not require permission to rename a local variable. It should not be allowed to invent a new distributed architecture without engineering approval. {% details An example: an architecture decision prompt for an AI agent %} Before implementing this feature: 1. Identify the affected domain boundaries. 2. Propose at least two viable solutions, including one that reuses existing infrastructure. 3. Compare: - Complexity - Reliability - Operational cost - Backward compatibility - Migration effort - Failure recovery 4. Explicitly identify assumptions and unknowns. 5. Recommend the simplest solution satisfying the documented requirements. 6. Do not implement until the architectural decision is approved. 7. If new information invalidates the approved design, stop and request a new decision. This is not a replacement for engineering expertise. It is a way to make that expertise visible in the workflow. {% enddetails %} The developer's role is changing, but not disappearing I do not think the future of software engineering is developers manually writing every line of code. Nor do I think it is developers approving whatever an autonomous agent produces. The interesting future lies between those extremes. Developers may spend less time producing routine implementations and more time defining constraints, exploring tradeoffs, validating behavior, and managing complexity. But there is a danger in describing this transformation as developers becoming merely supervisors of AI agents. Supervision without sufficient technical understanding is fragile. If developers stop exercising implementation and architectural judgment, their ability to challenge increasingly sophisticated AI proposals may deteriorate. We could end up with systems that are easier to generate than to understand. And organizations that can produce software faster than they can responsibly maintain it. That would not be an improvement in software engineering. It would be an improvement in software production at the expense of engineering control. The real test of AI-DLC I am interested in AI-DLC, Bolts, and spec-driven development because they attempt to solve real problems: lost context, slow handoffs, inconsistent implementation, and repetitive work. I also think they deserve more rigorous evaluation than demonstrations of rapid application generation. The most convincing evidence would be a substantial production platform developed and maintained through many AI-driven iterations, with its architectural decisions, specification changes, failures, and operational history available for examination. Not just the first successful release. The tenth feature. The unexpected migration. The production incident. The architectural decision that turned out to be wrong. And the developer who recognized the mistake before an autonomous agent made it worse. {% card %} The goal should not be to remove developers from the decision-making process. It should be to give developers better information, more alternatives, and greater leverage over the decisions that matter. An AI engineering methodology succeeds when it improves engineering judgment—not when it makes that judgment optional. {% endcard %} Final thought AI can propose a solution in seconds. It can generate thousands of lines of code, construct tests, document decisions, and execute an entire development workflow. But engineering has never been only about producing implementations. It is also about knowing when an implementation should not exist. When an abstraction is unnecessary. When a dependency introduces more risk than value. When a requirement is incomplete. When a system should remain simple. And when execution must stop. The most important AI engineering skill may not be writing better prompts. It may be knowing when to say no. --- Further reading - AWS — AI-Driven Development Life Cycle: Reimagining Software Engineering - AWS — Building with AI-DLC using Amazon Q Developer - AWS Labs — AI-DLC Workflows - specs.md — AI-native development workflows - The Scrum Guide (2020) What do you think? Are AI-native development methodologies giving engineers more control over software design, or gradually turning them into reviewers of decisions made by agents?

> /aidlc-session-cost and /aidlc-replay print to the terminal and write nothing; /aidlc-outcomes-pack is the only one that writes a file (OUTCOMES.md at the workspace root). github.com/awslabs/aidlc-workflows/blob/main/docs…

AI-DLC Workflows v2 よい。はじめ「？」っとなったが、IntentsとCustom Scope使ったハンドリングに慣れてくると心地よくなってきた github.com/awslabs/aidlc-workflows/tree/main

From Writing the Spec to Approving It: What AI-DLC Looks Like on a Real Build !Image description Most AI-assisted development still follows the old split. A human writes the spec, a human writes the code, and the AI helps with autocomplete or generates tests at the end. AI-DLC (the AI-Driven Development Life Cycle) reverses that. The AI drafts the requirements, the design, and the code. The human answers short questions and approves each stage before the next one starts. To see what that looks like in practice, I built a small command-line tool with it and then read the record the workflow left behind. This post walks through that record, folder by folder. > TL;DR > - AI-DLC is public and open source: awslabs/aidlc-workflows. The method comes from this AWS DevOps blog post. > - My only written input was one sentence. Everything else I did was pick options and approve gates. > - The run produced requirements, four architecture decisions, a unit plan, a traceability file, and 12 tests that passed when I ran them, in about 44 minutes from start to the code approval. > - The human role moves from author to decision-maker. The decisions are still yours, and the record shows where they changed the outcome. The app The tool is a Spooky Date Fact Generator. It picks one of 10 spooky dates (or takes --date MM-DD) and prints a spooky event for that day from Wikipedia's "On this day" feed. It is small on purpose. The whole request was this sentence: /aidlc build random date generator with fact around that number The flip, in one table | | Traditional with AI help | AI-DLC | |---|---|---| | Requirements | Human writes them | AI drafts them from multiple-choice answers | | Design | Human sketches it | AI proposes, human picks between options | | Code | Human writes, AI assists | AI writes against an approved plan | | Tests | Human or AI at the end | AI writes them to the stated requirements | | Human job | Author | Decide, validate, approve | | Evidence | Pull request diff | Audit log, decisions, traceability file | Where everything was written Two locations matter. The generated app sits in its own folder, and the workflow record sits in an aidlc/ folder. app/ <- the generated tool src/spooky-facts.ts core: dates, fetch, keyword filter, nearest-date search src/cli.ts command line: options, output, exit codes test/ 12 tests, offline, with a fake fetch package.json, biome.json, tsconfig.json, README.md aidlc/ codekb/ <- 9 docs about the existing repo intents/<date>-date-fact-generator/ <- the record for this build aidlc-state.md stage checklist and settings audit/ every event, decision, and approval inception/ reverse-engineering/ scan of the existing repo requirements-analysis/ questions + requirements.md domain-design/ questions + components.md + decisions.md units-generation/ unit-of-work files construction/u1-spooky-date-cli/code-generation/ code-generation-plan.md, code-summary.md, unit-test-instructions.md, traceability.json Each stage writes a -questions.md file, and your answers sit in the same file as the AI's questions. That makes the decision trail readable without any tooling. Stage by stage: what it did and why it helps Initialization. The workflow scaffolded the record folder, scanned the workspace, and classified it as brownfield TypeScript on Bun. This is automatic. It helps because every later stage starts from facts about the repo instead of guesses. Reverse Engineering. A developer agent scanned the existing repo and wrote nine knowledge-base documents (architecture, technology stack, code structure and others). This matters most in a brownfield repo. The later code followed the repo's Bun, TypeScript, and Biome conventions because the AI had read them first. Requirements Analysis. The AI asked six questions, such as where facts come from, what to do when a date has no spooky event, and whether this should be a web page or a command line. Each had lettered options. I answered, and one answer included a free-text note: generate dates that have spooky facts, from 10 such scenarios. The result is requirements.md with 15 functional and 5 non-functional requirements, each with acceptance criteria and a tag pointing back to the answer that produced it, such as [Q5]. This stage turns one vague sentence into testable statements before any code exists. Domain Design. Four more questions produced components.md and four architecture decision records. The AI recommended splitting the tool into four parts. I chose two. The decision record states that the four-part split was rejected as more structure than needed. This is the clearest example of the validator role, because the human overrode the AI's recommendation and the reason is recorded. Units Generation. One question: build as one unit or two. I chose one, approved the plan, and got unit-of-work.md with boundaries, responsibilities, and constraints. It fixes the blast radius. The unit is limited to apps/date-fact-generator/, and nothing in the framework folders may change. Code Generation. The AI wrote a plan, then the code, then the tests. It asked one thing here: Bun was not installed, so should it install Bun or switch to Node. I chose Bun. The code-summary.md lists files created, decisions made, and deviations from the plan. One deviation worth noting: the AI added word forms such as "dies" and "sank" to the keyword list, because whole-word matching would otherwise miss "Houdini dies". The summary also states that some planned checks were grouped into fewer tests to match the 12-test count. Build and Test. In the record I read, this stage was still marked in progress, so its summary was not written yet. I ran the checks myself from the app folder: 12 tests passed with 93 assertions, and lint and typecheck were clean. What the human actually did Reading the audit log, the human work was this: - Typed one sentence to start. - Approved a recomposed plan. The workflow's planner found the default express plan was missing inputs for later stages, and proposed adding Domain Design and Units Generation while dropping deployment and monitoring. - Answered 11 multiple-choice questions across three stages, plus two more decisions: build inside the existing repo, and install Bun. - Approved 5 stage gates: reverse engineering, requirements, domain design, units, and code generation. That is the flip. Nothing in that list is writing a spec or writing code. All of it is deciding and checking. Why this holds up better than a prompt Two details make the validation real instead of a rubber stamp. First, traceability. traceability.json maps every requirement ID (FR1.1 through NFR5, 20 in total) to the file that satisfies it. If a requirement has no target, it shows up. Second, the record is complete. The audit log holds the timestamp of each question, answer, and approval. A reviewer six months later can see why the design has two components and not four. What this run does not show This was an express-scope build of a 658-line app, with plan approval, sensors, and learnings switched off by the scope. It shows the shape of the method, not how it behaves on a large system with many units and teams. The Build and Test stage had not completed in the record, and the tests are offline, so only one manual live smoke run, recorded in the code summary, exercised the real Wikipedia feed. The questions are only as good as the options offered. A weak option list can steer a hurried approver, so reading the alternatives still matters. Takeaway The useful change is not that the AI writes more code. It is that the human's time moves to the points where judgment counts: what the tool should do, which design to accept, and whether the result meets the requirements. If you want to try it, start with a small brownfield repo and read the -questions.md files first. They show the method faster than any description.

【ハーネスエンジニアリング】AI-DLC v2で割り勘計算アプリを作ってみた はじめに 最近はAIエージェントを使った開発がすっかり当たり前になってきています。AIエージェントに組み込んで使う、いわゆる「ハーネス」のツールやスキル、プラグインなども豊富にあって、どれを使えばいいのか迷ってしまうほどです。 本記事では、そうしたツールの一つであるAI-DLC v2を使って割り勘計算のシンプルなWebアプリを作り、AI駆動開発の流れを体験します。 結論からいうと、AIが質問し、人間が承認して進む流れは最後まで崩れず、アプリを完成させられました。ただし、承認時に表示される要約だけでは、回答で決めきれていなかった点に気づけず、レビュー結果のファイルを直接読む必要がありました。 ! 本記事は、AI-DLC 2.10.0とGitHub Copilot CLI 1.0.88の組み合わせで、スコープpocを1回実行したときの記録です。 AI-DLCとは AI-DLC（AI-Driven Development Life Cycle）は、AWS Labsが公開している、AIが主導して開発を進めるためのワークフローです。Claude Code、Kiro、Codex、Cursor、GitHub CopilotなどのAIコーディングツールに組み込んで使います。 AIからの質問に答えていくことで要件定義書や設計書、コードなどの成果物が生成され、人間がそれを承認していく流れで開発が進むのが特徴です。 開発は次の5つのフェーズを順に進みます。 フェーズ やること Initialization 作業フォルダの準備 Ideation 目的と範囲の整理 Inception 要件定義と設計 Construction コード生成とテスト Operation デプロイと運用 各フェーズは、intent-capture（意図の把握）やrequirements-analysis（要件分析）といったステージ（全33種類）の組み合わせでできています。ステージの終わりには人間が承認する場面（承認ゲート）があり、承認するまで次のステージには進みません。 AI-DLC v1とv2の違い AI-DLC v1は、InceptionとConstructionの2フェーズを、ステージごとに1回承認しながら進む流れでした。v2では、この流れが前後に広がり、作業の種類に合わせて実行するステージを選べるようになりました。 ステージの選び方のプリセットを、v2ではスコープと呼びます。新規プロダクトの最小版（MVP）を作るならmvp（23ステージ。Operationを省く）、新機能の開発ならfeature（33ステージすべて）、実現可能性の検証ならpoc（8ステージ）、バグ修正ならbugfix（9ステージ）というように、11種類が用意されています。v1と同じ流れはclassicとして残っています。どのスコープにも当てはまらない場合は、composerという仕組みがステージ構成を提案します。 ほかにもv2では、CopilotやClaude Codeなど複数のAIコーディングツールで同じエンジンが動くようになりました。成果物と進行状況は、監査ログとしてファイルに残ります。 導入方法 ! GitHub Copilot CLI（1.0.74以上）がインストール済みで、ログインできる状態を前提とします。Copilot CLI自体の導入手順は、GitHubの公式ドキュメントを参照してください。 1. AI-DLCをインストールする macOS・Linux・WSLでは、次のコマンドでインストールします。ここではv2.10.0を指定しています。 ターミナル curl -fsSL github.com/awslabs/aidlc-workflows/releases/downl… | sh -s -- --version 2.10.0 ! このコマンドはrootユーザーではなく一般ユーザーで実行してください。 WindowsのPowerShell向けの手順は、公式READMEを参照してください。 2. 作業フォルダに設定する 作業フォルダに移動し、AI-DLCをCopilotから使う設定をします。--harnessには、AI-DLCを組み込む先のAIコーディングツールを指定します。 ターミナル mkdir warikan && cd warikan aidlc config --harness copilot 対話で聞かれる項目は、次のように答えました。 項目 選択 Record settings project Models Enter（Copilotのセッションモデルを使う） Provider 1（keep current） 3. 動作を確認する 同じフォルダでCopilot CLIを起動します。 ターミナル copilot ! フォルダを信頼するかを聞かれたら、「常に信頼する」選択肢を選びます。信頼しないと、AI-DLCのフックが警告なしに無効になります。 起動したら、次を入力します。 Copilot内で入力 /aidlc --doctor 0 problemsと表示されれば準備完了です。 割り勘計算アプリを作る: 8ステージ・承認5回で完成 起動: 指示は「フロントのみ・保存なし」だけ AI-DLCからの質問で仕様が固まっていく様子を見たかったので、起動時の指示は最小限にしました。技術スタックや細かい仕様は書いていません。 Copilot内で入力 /aidlc 割り勘計算アプリを作りたい。ブラウザだけで動くフロントエンドのみの Webアプリで、データは保存しない 既製のスコープがぴったり合わないとして、進め方を聞かれました。 Copilot内の表示 既製のプランがこのタスクにぴったり合いません。どう進めますか？ プラン: ❯ compose (recommended) express mvp feature Other (type your answer) composeを選ぶと、composerがステージ構成を提案してきます。提案には、33ステージそれぞれを実行するか（EXECUTE）飛ばすか（SKIP）とその理由が並びます。今回は8ステージを実行、25ステージを飛ばす構成で、既製のpocと同じでした。飛ばされた理由は「単機能・静的フロントエンドのみで、外部API・インフラ・運用要件がないため」でした。 この提案をApproveすると、ワークフローが始まります。 各ステージの進み方 質問のあるステージは、どれも同じ順序で進みます。 AI-DLCが質問ファイルを作る。各質問にはA〜Dの選択肢と「Other（自由記述）」がある 人間が質問に答える。チャットで順に答える（Guide me）か、ファイルを直接編集する AI-DLCが回答の要約を示し、合っているかを確認する 成果物が生成され、AIによるレビューが走る。判定（READY / NOT-READY）と指摘は、reviews/フォルダにファイルとして書き出される 人間がApprove（承認）かRequest Changes（修正依頼）を選ぶ 選択肢で迷ったときは、Otherで相談できます。AI-DLCが選択肢の違いと実装への影響を整理し、聞き直してくれます。 Ideation（目的と範囲の整理）: 目的と範囲を5つの質問で決定 最初のステージintent-captureでは、課題と利用者、成功の基準、きっかけ、決定権、製品の範囲の5問を聞かれました。端数の扱いのような細かい仕様は、ここではまだ聞かれません。 一番迷ったのは、課題と利用者を聞くQ1でした。Otherで相談すると、「均等割りのみ」「傾斜配分まで」「品目ごとの分担まで」の3段階に整理して聞き直してくれました。今回は傾斜配分（人によって割合や金額を変える）まで含め、品目ごとの分担は範囲外にしました。 成果物は、意図の記述書とステークホルダーマップです。レビュー結果はREADYで、軽微な指摘が3件ありました。「成功の基準が測定できない」などで、次の要件分析で具体化するとされたため、そのまま承認しました。 Inception（要件定義と設計）: レビューがNOT-READYで差し戻し requirements-analysisでは、仕様の細部を7問聞かれました。Ideationの指摘を受けて、「結果が表示されるまでの速さ」のような測れる基準の質問も入っています。ここでは、主な2つの質問を紹介します。 requirements-analysis-questions.md（抜粋） Q1. 端数の扱い A. 1円単位で切り上げ、集める合計が少し多くなる分は「余り」として画面に明示する B. 1円単位で切り捨て、足りない分を「幹事が負担する額」として画面に明示する C. 1円単位に丸め、余りの 1円ずつを何人かに配分して、合計をちょうど一致させる D. 100円単位など、切り上げる単位を利用者が選べる Q2. 傾斜配分の指定方法 A. 人ごとに割合(重み)を指定する(例: 先輩1.5、後輩1、幹事0.5) B. 人ごとに固定金額を指定し、残りを他の人で割る(例: Aさんは 2,000円、残りは均等) C. Aと Bの両方に対応する Q1はD、Q2はCと答えました。残りの5問では、日本円の整数のみ、参加人数は2〜50人、入力のたびに1秒以内で自動再計算、日本語のみ、技術はおまかせ、を選びました。 ところが、Q1のDには「切り上げで多く集まった分（余り）をどう扱うか」が含まれていませんでした。回答した時点では、余りの扱いを決めていないことに気づいていませんでした。回答の要約でも「矛盾なし」とされ、聞き直されることはありませんでした。 これに気づいたのは、要件定義書の生成後に走ったレビューです。判定はNOT-READY、指摘は6件（重大度は高2・中3・低1）でした。高の2件は「固定金額の人にも切り上げ単位を適用するか」と「切り上げ単位の選択肢の食い違い」で、どちらもQ1の考慮漏れが原因です。AIが自分で作った要件定義書をセルフレビューし、回答した筆者も見落としていた点を指摘できていたことには感心しました。 Request Changesを選ぶと、「指摘をすべて反映し、未解決の点はAIが妥当な案を決める」などの進め方が示されます。今回はAIに決めさせず、次のように具体的な修正を指示しました（FR・NFRは、要件定義書で機能要件・非機能要件に振られた番号です）。 Copilot内で入力 次のとおり修正してください。 1. 固定金額の人には切り上げ単位を適用せず、指定した金額のままとする。切り上げは割合で配分する人だけに適用する 2. 切り上げ単位の選択肢は 1円・10円・100円の 3つとし、初期値は 1円とする。 3. 割合配分で丸めが起きる場合の余りの定義と数値例を追加する。FR3.3は余りの定義に合わせて書き直す 4. 異常系を追加する：合計金額は 1円以上、割合は0より大きい数、全員が固定金額で合計金額と一致しない場合はエラー 5. 出典のない要件（NFR4〜6、FR2.3〜2.5）は、前提として扱うことを明記する 6. 1秒の計測条件と、スマホの画面幅（例: 360px）を明記する 修正後の再レビューはREADYでした。受け入れ基準の数値例4件も、レビューの中で検算されています。低の指摘が3件残りましたが、そのまま承認しました。 Construction（コード生成とテスト）: 計画を承認し、コードとテストを生成 Constructionのcode-generationでは、質問の代わりに、コード生成の計画への承認を求められます。提示された計画の要点は次のとおりです。 項目 内容 形態 素のHTML/CSS/JavaScript。サーバー・ビルド・外部ライブラリなし 計算ロジック src/calc.js。浮動小数点の誤差を避けるため、BigIntの整数計算のみ 画面 index.html・styles.css・src/app.js。入力のたびに自動で再計算 テスト Node.js標準のnode:testで計算ロジックを単体テスト。画面は手動で確認 技術スタックは、Inceptionで「おまかせ」と答えていたため、ここで初めて決まりました。 計画には、要件にない前提が1つ入っていました。「割合は小数第2位まで、上限なし」です。これはInceptionの再レビューで残した低の指摘（割合の桁数と上限が未定義）への対応で、計画自身が「承認時に確認してほしい」と明記していました。検証用の小さなアプリなので、この前提のまま承認しました。 承認すると、作業フォルダにアプリ本体と単体テストが生成されます。 フォルダ構成 warikan/ ├── index.html ├── styles.css ├── package.json ├── README.md ├── src/ │ ├── app.js # 画面 │ └── calc.js # 計算ロジック └── tests/ └── calc.test.js # 単体テスト（13件） 承認時の要約は「重大な指摘なし」でした。ところが、reviews/review-01.mdを開くと、指摘が3件（低2・情報1）書かれていました。たとえば次の2件です。 index.htmlをダブルクリックで直接開くと動かず、静的サーバーが必要になる 画面を自動で確認するテストがない どちらもpocの範囲としては許容できるので、修正せずに承認しました。ただ、要約だけを見ていたら、気づかずに通していたはずです。要約を鵜呑みにせず、ファイルを自分の目で確かめておいてよかったと思いました。 続くbuild-and-testでは、テストが実行されました。13件すべて成功し、50人分の計算は、計算ロジックだけで約0.5〜1.3msでした。画面の確認はAI-DLCの工程に含まれず、人に委ねられます。そこでブラウザで開き、次の4点を確かめてから最後の承認をしました。 幅360pxの画面でも操作できる 画面が日本語で表示される 入力のたびに自動で再計算される 通信が発生しない できたアプリ 合計金額と人数を入れると、1人あたりの額が自動で表示されます。人ごとに割合か固定金額を指定でき、切り上げ単位（1円・10円・100円）で生じた余りも表示されます。 まとめ AI-DLC v2で割り勘計算アプリを作り、8ステージと承認ゲート5回を経て完成させました。起動時に伝えたのは「フロントのみ・保存なし」だけでしたが、目的と範囲、仕様の細部、技術スタックの順に、段階を分けて聞いてくれました。端数の扱いのように自分でも詰めきれていなかった論点を、質問の形で突きつけてくれるのは心強いです。また、要件定義書等のドキュメント以外に、こうした質疑応答の内容もすべてファイルとして保存しておいてくれるのは、作業を中断して再開するときや、後から振り返るのに非常に役立つと思いました。 その一方で、承認時に表示される要約はあまり当てになりませんでした。Inceptionでは、要約が「矛盾なし」とした回答に、レビューがNOT-READYを出しました。Constructionでは、要約が「重大な指摘なし」だったのに、レビューファイルには指摘が3件ありました。AI-DLCを使うときは、承認の前にreviews/のファイルと計画の前提を開いて読むことをおすすめします。また、アプリの画面はAI-DLCの工程では確認されないので、人間が確かめる必要があります。 今回は小さなアプリの作成をpocで1回試しただけなので、ほかのスコープや題材では違う動きをするかもしれません。機会があればmvpやfeatureのような、ステージの多いスコープも試してみたいと思います。

信頼性とRintime配布に関する改善な感じなのかな🫣 github.com/awslabs/aidlc-workflows/releases/tag/v…

チームの自律性を失わずにAI駆動開発を導入するために大切なこと シンプレクスでエンジニアをしている清家です。 エンタープライズアプリケーション開発における生成AI活用の主要な関心は、個人の生産性向上からチームの生産性向上に移ってきていると感じます。 チームの生産性を改善する方法の一つとして、AI駆動開発ワークフロー（以下、ワークフロー）を設計し、現場に導入することが考えられます。一方で、ワークフローを現場の開発プロセスに適合させるだけでなく、チームがその仕組みを理解し、継続的に改善できる状態を作ることも重要です。 生成AI活用に詳しいメンバーが作ったワークフローを、他のメンバーが中身を十分に理解できないまま使うようになってしまうと、開発プロセスはチームのものではなくなります。 現在、私が参加しているプロジェクトでは、スクラムをベースに、AWSが提唱するAI駆動開発の手法「AI-DLC」を導入しました。 その中で、私は主にAI-DLCをベースとしたワークフローの構築と、チームへの導入を担当しました。 この記事では、AI-DLCをベースとしたワークフローをスクラムチームが自律的に改善し続けるために、私が現在も重視していることを書きます。 AI-DLCとは AI-DLC（AI-Driven Development Life Cycle）は、AWSが提唱するAI駆動開発のフレームワークです。 完全自律型のAI駆動開発を目指すのではなく、AIが提案する設計や作業計画に人間が伴走しながら、意思決定を行う手法です。 speakerdeck.com また、ワークフローのプロンプトがOSSとして公開されており、各チームの開発プロセスに合わせてカスタマイズできます。 github.com/awslabs/aidlc-workflows/tree/v1 公開されているAI-DLCのワークフローは、主に以下のフェーズで構成されています。 Inceptionフェーズ 高レベルな意図を、ユーザーストーリー、非機能要件、開発単位などに分解します。AIは曖昧な点を質問し、人間は意思決定と成果物の確認を行います。 Constructionフェーズ ドメイン設計、論理設計、コード生成、テスト生成といった開発作業を進めます。AIは設計書やコードを生成し、人間は重要な設計判断やレビューを担います。 Operationフェーズ テレメトリや運用情報をもとに、異常検知や改善提案を行います。人間はAIの推奨事項を検証し、実際に採用するかを判断します。 私たちのチームでは、OSSで公開されているワークフローをベースに、今回のプロジェクト向けに最適化して開発を開始しました。 例えば、私たちのプロジェクトでは、デザインチームが先にFigmaでUIを作成する開発プロセスを採用したため、InceptionフェーズでFigmaを入力として要件を決定し、作業計画を立てられるようにカスタマイズしました。 このように、AI-DLCの価値は「完成されたワークフロー」ではなく、「AIと人間がどう協働するかを、チームごとに設計できる土台を提供してくれること」だと思います。 チームがワークフローを自律的に改善できるようにする価値 マイクロソフトのプロフェッショナル開発者448名を対象に、AIによるタスクの自律的な実行に対する許容度を調査した論文が、2026年7月に公開されました。 arxiv.org 論文中の開発者調査では、「自分のアイデンティティを定義する仕事については、AIによる自律的な実行を許容する度合いが低い」ことが示されました。 論文では、自分のアイデンティティを定義する仕事を、開発者がどれだけ楽しめるか、またタスクの遂行が自らの職人意識にどれだけ直結するかという度合いが高いタスクだと説明しています。 これを読んだ時、ワークフローを最初の構築した人だけでなくワークフローを使って開発を行う各メンバーが、AI駆動開発プロセスを進化させていける状態を目指すことが重要だと思いました。 そのため、私はワークフローの初版を構築した後、スクラムチームが自分たちでワークフローを改善しやすい方法を考えるようになりました。 チームがコントロールできるワークフローを作るために大切だったこと 今回の取り組みを通じて、チームがワークフローを主体的に改善するために重要だと感じたのは、次の3点です。 フルサイクル開発者がプロジェクトの制約を踏まえたワークフローを設計する 最初から複雑にしすぎず、チームの認知負荷の急激な上昇を避ける ワークフローを継続的に改善しやすくする 開発ライフサイクル全体を俯瞰し、プロジェクトの制約を踏まえてワークフローを設計する AI-DLCを導入するとき、私が最初に検討したのは、プロジェクトの特性に合わせてソフトウェア開発ライフサイクル（SDLC）を設計し、AIと人間がどの工程でどう協働するかを定めることです。 OSSとして公開されているワークフローのプロンプトは、あくまでAI駆動開発の「型」として捉えました。そのうえで、プロジェクトに合わせてワークフローをカスタマイズする作業を、開発を始める前に行いました。 ここで重要になるのが、フルサイクル開発者の視点です。フルサイクル開発者という言葉は、2018年に公開されたNetflixのテックブログに由来します。 netflixtechblog.com 要件整理、設計、実装、テスト、リリース後の保守までを具体的にイメージできるエンジニアがワークフローを設計することで、必要なハーネスを作成し、AIに任せる領域と人間が品質を担保する領域を現実的に設計できます。 それに加えて、工程別に発生するプロジェクト特有の制約を踏まえて設計することも必要です。 例えば、接続先システムとの結合テストをワークフローにどう組み込むかを検討する場合を考えます。接続先システムでのテスト準備に時間がかかる可能性を把握できていれば、コード生成の直後に接続先システムとのテストをAIに実行させるようなワークフローにはせず、結合テストの仕様書を出力させるだけにとどめるという判断ができます。 フルサイクル開発者がSDLCの各工程における制約を踏まえてワークフローを作成することで、人間の活動とAIによる作業を無理なく両立できます。 最初から複雑にしすぎず、チームの認知負荷の急激な上昇を避ける ワークフローの初期構築でもう一つ重要なのは、チームの認知負荷が急激に高まることを避けることです。 開発が始まる前に、プロジェクトで想定できるすべての課題に対応するワークフローを作りたくなります。 しかし、その結果として、多くのハーネスやルールが生まれます。その状態でワークフローをチームに共有すると、チームが理解しなければならないプロンプトが膨大になります。これは、チームがワークフローを自分たちで制御する力を奪うことにつながります。 何のために存在するルールなのか、どこを変更してよいのか、変更すると後続工程に何が起きるのかが分からない状態では、チームはワークフローを改善できません。 そのため、最初から重厚なワークフローを目指さず、OSSで公開されているプロンプトには、主に以下だけを加えました。 AI-DLCの一連の流れを開始する実行コマンドの作成 AI-DLC開始時に人間がデザインファイルや仕様書を渡すステップの追加 生成されたコードが仕様を満たすことをテストするステップの追加 私たちの場合は、上記のカスタマイズだけでもチームが理解するまでに時間がかかりました。 もしかすると、OSSで公開されているワークフローを参考に、もう少し単純なステップから始めたほうがよかったかもしれません。 ワークフローを継続的に改善しやすくする チームでAI-DLCを使い始めると、当初のワークフローに対する改善も始まりました。 そのなかで、チームが自律的な改善を継続するうえで必要なことも分かってきました。私たちのチームでは、以下を行っています。 ワークフローの変化をチームで理解できるようにする ワークフローの課題をチームで発見し、改善につなげる ワークフローの変化をチームで理解できるようにする AI-DLCのワークフローを変更したときに、変更履歴を残す仕組みを導入しました。 ソフトウェアアーキテクチャの意思決定をADR（Architecture Decision Records）として記録するように、ワークフローの変更も記録します。 コーディングエージェントがAI-DLCのワークフローのプロンプトに変更を加えると、フック（hooks）が起動して変更履歴ファイルを作成する仕組みです。 AIDLC-XXX: {改善タイトル} 起票日: YYYY-MM-DD 対応日: YYYY-MM-DD 発見経緯: {ユーザ要望 / 開発中の気づき / レビューでの指摘} 背景課題 {なぜこの改善が必要だったのか} 対応内容 {何を変更したか} 期待される効果 {どう改善されるか} この変更履歴により、将来ワークフローを変更しようとしたときに「なぜこのルールがあるのか」を確認できます。 背景課題が分かれば、不要になったルールを削除する判断もしやすくなります。逆に、過去に同じ問題が起きて追加されたルールであれば、安易に消さない判断もできます。 新しいメンバーの参加時やワークフローの変更時に全体像を把握できるよう、構成を可視化するスキルを作成しました このスキルを実行すると、AI-DLCのワークフロー全体が可視化されたドキュメントが出力されます。 各フェーズ・ステップの目的 各ステップで出力される成果物 その成果物を参照している後続ステップ ワークフローの全体像が見えると、新しく入ったメンバーも「このステップで生成される設計書は、どこで使われるのか」を理解しやすくなります。 変更履歴と可視化ドキュメントがあることで、ワークフローは一部のメンバーだけが知っている暗黙知ではなく、チーム全体で扱える資産になります。 ワークフローの課題をチームで発見し、改善につなげる 私たちのチームでは、個人の開発時とチームのレトロスペクティブの両方から改善の種を集めています。 まず、個人が開発中に行う取り組みとして「Working Out Loud」を実践しています。 blog.studysapuri.jp AI-DLCによる開発を進めながら、私たちはSlackに自分の作業を実況しています。そうすることで、「ワークフローのこのステップがスキップされている、変だな」「このステップの成果物の精度が著しく低いぞ」というような課題を、チーム全員が見られる場所にリアルタイムで共有できます。 そして、チームのレトロスペクティブでは、スプリント中の動き方、プロダクトバックログアイテムをインクリメントにするまでのリードタイム、Slackに投稿された個人の作業ログを見ながら、ワークフローの改善ポイントを見つけ出します。 レトロスペクティブで発見した課題のうち、改善効果が高そうなものを次のスプリントバックログアイテムとして扱い、ワークフローのプロンプトに反映します。 このサイクルにより、ワークフローの改善が「AIに詳しい人の個人的な工夫」ではなく、チームの経験に基づく開発プロセス改善になります。 AI-DLCを導入して開発するなかで分かってきたこと これらの仕組みは初版からすべて備えていたわけではなく、チームで開発を進めるなかで段階的に導入してきました 結果として、今でもワークフローの仕組みに対する理解度にはメンバー間で差があると感じます。しかし、全メンバーが自分たちで発見した課題をワークフローにフィードバックできています。 それを可能にしているのは、チームが自律的にワークフローを改善していける仕組みづくりだけでなく、基盤となるAI-DLCのワークフローの拡張性でもあると感じます。 AWSは2025年に「Open-Sourcing Adaptive Workflows for AI-Driven Development Life Cycle (AI-DLC)」というブログ記事を公開しています。 aws.amazon.com そのブログでは、プロジェクトごとの多様性を考慮したワークフローでなければ、プロセスにオーバーヘッドが生じ、生産性は向上しないと述べられています。 Software development has never been a linear process. In practice, different projects follow distinct pathways with their own checkpoints and deliverables. Consider these examples: AI-DLCのワークフローでは、開発対象の複雑さに応じて自律的に実行する作業の深度を調整できます。さらに、ステップを入れ替えたり削除したりしやすい点にも、上記の思想が反映されているのだと感じます。 今後、AI駆動開発を導入しようと考えている方の参考になれば幸いです。

人間が見るのは設計書だけ ― PdM不在・バグ修正中心のチームで、AI-DLCを開発フローごと作り直した話 はじめに カンリーでトストアの開発を担当している鈴木です。 トストアは、Google ビジネスプロフィールや Yahoo!プレイスなど、複数の地図・検索サービスに掲載する店舗情報・クチコミ・投稿を、企業がまとめて管理できるサービスです。もともとは別の会社のプロダクトでしたが、事業譲渡を経てカンリーに加わりました。現在は、将来的にメインプロダクトの「カンリー店舗集客」へ統合することを見据えて、安定稼働を守る保守の段階にあります。 AI-DLC（AI-Driven Development Life Cycle）は、AI をコーディングだけでなく、要件定義・設計・実装・テストまで開発ライフサイクル全体で使うための考え方です。私が AI-DLC を知ったのは今年に入ってからでした。4 月に社内でワークショップが開かれ、「それぞれのチームに持ち帰って、開発フローに落とし込んでほしい」と求められたのが、この記事の出発点です。 同じワークショップに参加した店舗集客チームは、PdM を交えたモブで合意形成する形を取りました。一方トストアでは、モブをやめ、Claude Code のスキル 11 個に落とし込むという形に落ち着きました。 ! この記事のポイント バグ修正が中心のチームでは、「本来こう動いてほしい」という期待仕様を intent にし、原因調査を前段のスキルに切り出した スキルは公式のワークフローを使わずに自作した。手で一巡してから AI に逆算させ、型になるまで自分だけで使い込んでから、チームに広げた 人間のレビューは設計書に絞り、実装のチェックは AI のレビューと全項目の動作確認に任せるようにした（性能やセキュリティまでは保証できない、という限界はある） 設計書とコードコメントの PBI 番号が残るようになり、バグの記録と追跡の質が大きく変わった。一方で、1 件あたりの作業の速さは上がっていない この記事で使う用語 PBI: プロダクトバックログアイテム。開発の作業単位で、トストアでは Jira のチケット 1 件にあたる（TM-9190 のような番号が付く） Unit（ユニット）: 1 つの PBI を実装しやすい単位に分けたもの。TM-9190 U1 は「TM-9190 の 1 つ目のユニット」の意味 インセプション / コンストラクション: AI-DLC のフェーズ名。インセプションで「何を作るか」を固め、コンストラクションで設計と実装を進める。エラボレーションは、インセプションの中で要件を詰める工程 モブ・エラボレーション / モブ・コンストラクション: 複数人が同じ画面を見ながら、AI と一緒に要件を詰めたり実装したりするやり方 スキル: Claude Code に作業手順を覚えさせる仕組み。本文では intent のように短く書いているが、実際の名前は /ai-dlc-intent のように頭に ai-dlc- が付く（start・review・pr なども同様。incident-triage・pbi-ticket・qa-support はそのまま） ワークショップの型と、トストアとのギャップ ワークショップのチームは、PdM 1 名とエンジニア 4 名ほどという構成でした。私が入ったチームでは、PdM から出た「次に作りたい機能のモックを作って、イメージを膨らませたい」という希望をお題にしました。モブ・エラボレーションで PdM と議論しながらインセプションを進め、モブ・コンストラクションでモックを作るところまでやりました。 進めながら、私は「この形はトストアにはそのまま持ち込めない」と感じていました。理由は 2 つあります。 1. 仕事の性質が違う。 統合を見据えた保守の段階にあるので、トストアでは新しい機能はほとんど作りません。とはいえ、機能の改善やバグ修正をしないわけにはいかず、仕事は障害対応・調査・バグ修正が大半です。新規機能の開発なら AI-DLC の当てはめ方がすぐに想像できましたが、バグ修正にどう当てはめればよいかは分かりませんでした。 2. 体制が違う。 当時、トストアでフルコミットのエンジニアは 2 名（私と業務委託のメンバー）でした。もう 1 名いるエンジニアは他チームとの兼務のため、PBI に割ける時間は 2 割ほどでした。そして PdM は不在でした。私の理解では、PdM の大きな役割の 1 つは新しい機能の体験設計なので、新機能を作らない保守の段階では、置く必要性が薄いのです。 PdM と数名のエンジニアがモブで詰めていくスタイルは、この体制では成り立ちませんでした。そこでまず、「少人数・PdM 不在・バグ修正中心」という条件で AI-DLC をどう回すかを考えるところから始めました。 持ち帰るべきは、形ではなく考え方 考え始めてまず思ったのは、体制が合わないまま形だけを真似しても意味はない、ということでした。モブ・エラボレーションは、仕様を決める PdM がその場にいて、エンジニアとすぐに合意を作れるチームでこそ意味を持つやり方です。私が店舗集客チームの立場だったら、間違いなくモブ・エラボレーションを選んでいます。ですが、トストアにはその仕様を決める人がいません。開発者だけで集まり、インセプションの成果物を勢いよく書いていっても、得るものは少ないはずです。 私の理解では、AI-DLC の本質は、AI を開発の中心に据え、人間と AI の役割を入れ替えることです。これまでは、AI は道具で、人間がすべてをコントロールして頑張る、という世界観でした。AWS も、AI を補助役として既存のプロセスに後付けするだけでは AI の能力を制限し、古い非効率をかえって固定してしまうとして、開発ライフサイクル全体を AI ありきで作り直すことを説いています。 aws.amazon.com 当時のトストアの開発スタイルには、AI がなかった頃に慣習として定着したものが多くありました。そこに AI を道具として部分的に差し込んでも、よいものにはならないと思いました。 そこで私が目指したのは、intent から implement までのスキルに閉じず、その前後にも必要なスキルを足して、開発フロー全体を再定義することでした。調査も、起票も、試験項目書も、AI を前提に作り直す。そのうえで、AI に任せる部分と人間が判断する部分を峻別し、フロー全体を組み上げる。これが、私が AI-DLC をチームに持ち帰ってやったことです。 ただし、再定義といっても、すべてを根本から作り変えたわけではありません。全体の流れは、これまでの開発スタイルを踏襲するよう意識しました。毎日の昼会で Jira のチケットを眺めながらリファインメントとポイント見積もりをする。PR を出すときに、開発者自身が試験項目を書いておく。リリース前には、修正した箇所の試験を全項目こなし、必要に応じてデグレも確認する。こうした習慣は残しています。 大きく変えたのは、変えるべきところだけです。たとえば、新機能を作るときは設計書を書いていましたが、細かなバグ修正のたびに「何が壊れていて、どう直すか」の設計書までは書いていられず、場当たり的に進めていた部分がありました。こうしたところには、設計書を前提とする AI-DLC のフローをしっかり組み込みました。 根本からすべてを変えると、私自身もほかの開発者も覚え直すのが大変です。大きな変革は、プロジェクトの立ち上げ期のように、そのコストに見合う価値があるときにやるべきことだと思います。統合を控えた保守の段階で、ある程度うまく回っている流れを壊す理由はありません。実際にやったのも、今の作業のなかで「ここが不便だ」「自動化できたら便利なのに」と感じたところを、ひとつずつスキルに落とし込んでいくことでした。 モブをやめ、セルフで回すと決めた 最初に決めたのは、PdM の役割を誰が担うかでした。 PdM の役割は私が担う。 自分の PBI では、仕様を決めるところから実装まで自分でやる ほかの開発者にも、セルフで回してもらう。 ほかの開発者の PBI に私が毎回同席すると、ただでさえ手一杯のリソースがさらに削られる 大筋の方針は、毎日の昼会（リファインメント）で決める。 AI-DLC を回す途中で出てくる細かい問いには、担当者が裁量を持って答える 期待どおりの仕様になっているかは、最後に私が確認する 開発だけで判断できないことは、CS チームに聞く つまり、モブは完全にやめました。体制的に、これしか選択肢がなかったというのが正直なところです。 設計の段階でのレビューは、あえて挟まない 理想を言えば、インセプションが終わった段階で一度 PR を出し、方針が合っているかをレビューしてから実装に入るべきなのだと思います。設計が間違ったまま実装に進めば、手戻りが大きくなるからです。 ただ、それをやるには、私の設計はほかの開発者に、ほかの開発者の設計は私に、それぞれ見てもらって仕様に合意する必要があります。少人数のチームでは、そのコストを払えませんでした。 実際、これまでの 5 か月ほどで、担当者の判断が私の感覚と大きく外れて大修正になったことは一度もありません。担当者が Q&A の一つひとつで自分で判断し、その判断が的確だったおかげでもあります。 加えて、担当者は私の判断が必要だと思ったところで、Slack で声をかけたり、昼会で相談したりしてくれます。その場で解消しながら PBI を進めているので、ずれが後まで残りません。質問されなかった部分は、最後に PR で見ます。わざわざ集まってエラボレーションの時間を作らなくても、これで十分に吸収できています。 途中のレビューは挟まず、最後まで作り切り、動作確認まで終えたものを見て、必要なら直してもらう。今の人数に合った現実的な落としどころとして、この形に落ち着いています。 バグ修正を AI-DLC に乗せるには 次の問題は、新規開発向けに見える AI-DLC を、どうバグ修正に当てはめるかでした。 考えたのは、バグの裏には必ず「本来はこう動いてほしい」という期待仕様があるということでした。今はバグのせいで実現できていないけれど、本来はこうあるべき。その期待仕様を intent（何を実現したいか）として入力すれば、AI-DLC のフローに乗せられるはずだと考えたのです。 ただ、期待仕様だけでは足りないことも分かっていました。バグの原因です。何が壊れているのかが分からなければ、どう直すかの方向は定まりません。とはいえ、原因調査をフローのどこにどう組み込むのがよいかは、実際に回してみないと分かりませんでした。そこで最初は、原因調査を独立させず、intent を進めるなかで必要に応じて調べる前提で始めました。この判断がどうなったかは、後で触れます。 スキルを自作する AI-DLC を回す方法は決まりましたが、私だけが回せても意味がありません。ほかの開発者に展開するには、スキルとして型にすることが必須でした。 公式のワークフローを使わず、自作した理由 AI-DLC には、AWS が公開している公式のワークフロー（awslabs/aidlc-workflows）があります。その存在は知っていましたし、使うことも考えました。それでもスキルを自作したのには、はっきりした理由があります。 最初から、トストア独自のカスタマイズをたくさん入れるつもりだったからです。冒頭で触れたとおりトストアは事業譲渡で加わったプロダクトで、開発フローもトストアに合わせて育ってきたものなので、ここで作るスキルは、どうしてもトストアと密接に結びついたものになると考えました。社内でも、チームごとに最適化してよいという方針でした。先に触れたように、これまでの開発の流れを残したかったことも理由の 1 つです。既存のワークフローに乗るなら、流れの方をそちらに合わせることになります。 そうであれば、既存のワークフローを学んだうえでカスタマイズを差し込むより、自分で作ってしまう方が早く、確実だと判断しました。トストア向けの変更を、既存の流れのあちこちに差し込んでいく手間もかからず、他のチームと共有しないなら取り回しもよくなるからです。 他のチームに持っていくべきものは、スキルそのものではなく、スキルを作って AI-DLC を回した経験だと思っています。スキルは、極端に言えばトストアの開発が終われば役目を終える、使い捨てのものでも構いません。そう割り切ったからこそ、遠慮なくカスタマイズを進められました。 なお、公式のワークフローはその後 v1、v2 と版を重ねています。私の感覚では、トストアで育ったスキルは、ちょうどその v1 と v2 の間くらいのところにいます。この点は、トストアでの取り組みをひと通りお話しした後、最後に見比べます。 手で一巡してから、スキルを逆算する とはいえ、自作するといっても、ゼロからスキルを設計できるほど、私は AI に精通していませんでした。そこで取ったのが、次の手順です。 最初はスキルを作らない。 ワークショップで配られたプロンプトを手で入力し、AI と対話しながら AI-DLC のフローを一巡させることだけに集中する。題材には性質の違う PBI を 2 本選びました。1 本は、投稿関連のバッチ処理の有効・無効を企業単位で切り替える、小さな機能追加。もう 1 本は、投稿の処理中に編集や削除を受け付けてしまう隙間を塞ぐバグ修正です フローを一緒に体験した AI に、スキルを設計させる。 「どういうスキルにすれば、今の流れを型にできるか」を考えてもらう 成果物をお手本にして、逆算する。 一巡すれば成果物が手元に残ります。「これを同じ精度で再現するには、どんなプロンプトが要るか」は、お手本があれば逆算できます。いわばリバースエンジニアリングです AI にそこまで詳しくなくても、「体験済みの流れ」と「お手本の成果物」があれば、対話しながらスキルを作れます。チームに型を展開したい方には、一番真似しやすい部分だと思います。 型になるまで、チームに広げない この時期にもう 1 つ意識していたのは、型になっていないものをほかの人に展開しないことです。 当時は私自身も、スキルをどう作り、どう使って PBI をこなしていくのか、手探りの状態でした。そこにほかの開発者を集めても、混乱するだけで得るものはありません。そこで 4〜5 月は、私だけでスキルを作って使ってみる期間を、はっきりと設けました。いわば自分だけのドッグフーディングです。 スキルは AI に作らせているので、最初は私自身も、設計者というよりただの利用者です。自分で使いながら AI とやり取りして型を育て、「この状態ならチームに展開しても問題なさそうだ」と思えるところまで持っていく。逆に、この期間を挟まずに配ってしまうと、改善したくなるたびに、ほかの開発者のやり方まで変えてもらう必要が出てきます。 自分に閉じた期間には、「自分にとって使いやすい形」に寄ってしまう危うさもあります。だからこそ、ここで最も意識したのが、このスキルのことを何も知らない人の視点でした。物事が定着するかどうかは、結局のところ使いやすさで決まると思っています。いびつなフローや使いにくいスキルは、定着しません。 最初は利用者の視点で、自分の中で回るようにする。回るようになったら、提供者の視点に切り替える。「あれをしてください」「これをしてください」と頼まなくても、とにかく使ってもらえれば、流れに乗るだけで済む。そうなっているかを、使う人の目線で何度も確かめながら改善しました。後で紹介する「次のスキルの案内」と「自己改善」の仕組みも、この視点から生まれたものです。 ある程度満足のいく形になったところで、チームに公開しました。その後はフィードバックを受けて直しながら、今の形に育ててきました。 トストアは少人数なので私ひとりの期間になりましたが、大人数のチームでも、まず小さく試して型にしてから広げる順番は変わらないはずです。 スキルは 3 段階で育った 先に、今のフローの全体像を示します。 11 個のスキルの役割 スキル 役割 start 唯一の入口。新規なら作業環境を整えて振り分け、進行中なら現在地と次の一手を示す incident-triage 障害やバグの原因を、読み取り専用の調査で特定する pbi-ticket 調査結果をもとに、Jira のチケットを起票・更新する intent 何を実現したいか（バグ修正なら直し方の方針）を、質問に答えながら固める user-stories ユーザーストーリーと受け入れ基準を作る units PBI をユニットに分け、対象・対象外を列挙する domain-model ユニットごとに、実装の言葉を使わずに設計する implement 設計書（軽量レーンなら Jira の記載）を拠り所に実装する review 実装と設計書を手元でセルフレビューする pr PR を作り、Notion に試験項目のページを用意する qa-support 試験のシナリオを組み、動作確認を 1 つずつ案内する どのスキルも、実体は .claude/skills/ の下に置いた Markdown ファイル（SKILL.md）1 本です。 入口は start の 1 つだけです。原因が分かっていないバグ修正なら、原因調査と起票を経てインセプションに入ります。それ以外はそのままインセプションに入り、いずれもドメインモデルを拠り所に実装します。軽量レーンでは設計書づくりを飛ばし、Jira の記載を拠り所に直接実装へ進みます。記載が雑なときは、「対象範囲」と「完了の判定方法」の 2 点だけを確認します。 典型的なバグ修正 1 件の流れ ユーザーから「投稿が反映されない」と問い合わせが届く start を呼ぶ。hotfix かどうか、種別、原因は確定済みかを選択式で聞かれ、作業ブランチが用意される 原因が未確定なので incident-triage へ。関連するチケットを先に読み、読み取り専用のコマンドでログやデータを調べて、原因を特定する pbi-ticket で、調査結果ごと Jira に起票する。冒頭には 3 行サマリが付く 設計書が要る修正なら、intent から domain-model まで進む。AI の質問に答えながら、直し方の方針を決める（軽量レーンならここは飛ばす） implement で実装し、review で設計書との食い違いやコメントの PBI 番号のずれを点検する pr で PR を出し、Notion に試験項目のページを作る。レビューボットの指摘が収まるまで直す qa-support の案内に沿って動作確認し、最後に人間のレビュアーをアサインする このフローは、最初からこの形だったわけではありません。最初にできたスキルは 6 個で、そこから回すたびに不便が見つかり、足していった結果、今の 11 個になっています。git の履歴で追うと、次の 3 段階でした。 時期 追加したスキル 段階 5 月末 intent / user-stories / units / domain-model / implement / review 最初の型 7 月 start / incident-triage / pr 入口と原因調査 8 月 pbi-ticket / qa-support 起票と試験 5 月末: 最初の型 ワークショップのフローに沿って intent から implement までをスキル化し、そこにワークショップにはなかったセルフレビューの review を加えました。 intent では、AI が設計判断の要るところを人間に 3〜5 問ずつ質問します。PdM がいないぶん、問いを AI に出してもらい、担当者が答える形です。機能追加なら「なぜ必要か」という価値の判断が中心になります。一方、バグ修正では「正しく動くこと」自体が価値なので、問いの中心は「どういう方針で直すか」に移ります。units では対象・対象外をすべてのマス目で埋めさせ、domain-model では実装の言葉（関数名など）を禁止しています。 成果物の抜粋: バグ修正の intent（投稿の処理中に編集を受け付けてしまう不具合）## Intent（ビジネス目標） 投稿の「処理中」に、管理画面の操作（編集の確定・削除の確定）が隙間を通り抜けて 実行され、データの不整合に至る事象を防ぐ。排他制御の改善に加え、データの保存・ 上書きのロジックを見直し、想定外の経路でも整合性と復旧可能性を損なわないことで、 同種の事象の再発を抑えたい。 成功の定義: 投稿が処理中である限り、編集の確定と削除の確定は必ず拒否され、 データの整合性が保たれること。 付随する UX 上の方針 - 最優先: 上記の成功の定義（サーバー側の整合性と拒否）を満たす - その上で可能な限り: 処理中は編集画面に進めない。一時的に編集ボタンが 出てしまった場合も、確定時の整合性チェックで必ず弾く 以下、ところどころにスキルの実物を折りたたんで載せます。いずれも社外向けに一部を省略・変更しています。 スキルの抜粋: 対象・対象外を強制的に列挙させる（units）## スコープマトリクス（対象/対象外の強制列挙） 背景: スコープの取りこぼしは用語の定義に隠れる。ある用語の定義が一部の経路を 静かに除外し、ドキュメントに嘘はないまま承認を通過した。 対象の列挙だけでは、含まれないものが見えない。 レビュー依頼には、以下のマトリクスを必ず含めて承認を求めること: - PBI が触るドメインの主要な軸を特定する。投稿関連なら 「経路（新規/編集/削除/承認/再実行/一括/予約）× 媒体」。 それ以外は内容に合った軸を選ぶ（例: 操作種別 × 対象エンティティ） - 軸の値の列挙自体に漏れがないかも確認する。 セルの埋め忘れより、行や列ごと消えている方が気づきにくい review: ワークショップになかったセルフレビュー 開発者の手元で動くセルフレビューのスキル（review）も、最初から型に入れました。ワークショップにはレビューのプロンプトがなく、レビューを体験する内容もありませんでした。それでも足したのは、まず大前提として、実装したコードを手元でセルフレビューしたかったからです。そのうえで、ほかにも理由が 3 つありました。 1 つ目は、継ぎはぎになった設計書の矛盾を確かめたかったことです。Q&A を進めて後のフェーズに進むと、「さっきのフェーズでこう判断したけれど、AI が言っていたのは実はこういうことだったのか」「やっぱりおかしくないか」と、実装に近づくほど違和感が増していくことがありました。そのたびに改訂履歴を積んで前の判断を取り消し、AI が設計書を書き直していました。こうして継ぎはぎになった設計書が、最終的に全体として矛盾していないか、実装と食い違っていないか、コードコメントに書いた PBI 番号が設計書とずれていないかを、どこかで確かめる必要がありました。 2 つ目は、設計書そのものの抽象度を保ちたかったことです。序盤に作った設計書には、実装の詳細が漏れ出ているものがありました。もちろん、障害調査の結果であれば、テーブル名やファイル名といった実装の名前がどんどん出てきてほしい。そうでないと意味が分からないからです。一方で設計書に、クラス名・関数名・構造体名や、DynamoDB・S3 といった技術の詳細を書き込むと、抽象度が下がり、メンテナンスのコストも膨らみます。DDD の作法としても、純粋なドメインの言葉だけで書かれている方がきれいです。これを最後に点検したかったのです。 3 つ目は、コストです。GitHub Actions で動くレビューボットは、Claude のサブスクリプションの枠外（API の従量課金）で動くため、回すほどお金がかかります。一方、手元の Claude Code は会社で契約している Team プランの枠内で使えるので、定額の範囲で回せます。GitHub 上のレビューにすべてを任せるのではなく、手元で拾えるものは手元で拾っておくべきだと考えました。 7 月: 入口と原因調査 start: 悩みをすべて入口に引き受けさせる start を作った理由は 1 つではありません。回しているうちに出てきた悩みを、すべてこのスキルに引き受けさせました。 1 つ目は、軽量レーンが必要になったことです。印象に残っているのは、ログに値ではなくポインタのアドレスが出てしまっていた件で、本番コードの変更は数行でした。こんなものまで、intent から始めるフルコースの AI-DLC で直すわけにはいきません。 かといって、AI とその場で対話して直して終わり、にもしたくありませんでした。この程度の修正でも、アドレスではなく値が出るようになったことを確かめる試験は要ります。試験項目書を作り、PR を出し、マージされたものを動作確認する。開発フローとして必要なこれらの手順は、よほど特別な作業でない限り、すべてスキルでカバーしたかったのです。そこで、設計書づくり（intent から domain-model まで）だけを飛ばし、implement 以降は通常と同じスキルにつながる「軽量レーン」を設けました。 もう 1 つ、どこからを重量、どこまでを軽量とするかにはグラデーションがあります。判断基準が私の頭の中にしかないままでは、担当者は自分で決めにくく、毎回「フルで回しますか、軽量でいいですか」と私に確認することになります。少人数のチームでは、その確認さえ負担でした。このため、AI の方から判断基準を示して「軽量でやりますか」と聞くようにしました。基準が見えていれば、担当者が自分で決められます。 スキルの抜粋: 軽量レーンの判断基準（start）「この PBI は AI-DLC 適用ですか、軽量レーン（設計書を作らない修正）ですか？」 判断は人間が行うが、迷ったときの目安として以下の基準を併せて提示する。 設計書を残すのは、次のどれかに当てはまるときだけ: | 当てはまるもの | 残す成果物 | |--------------------------------------------------------|----------------------| | ① 合意が要る（仕様・UX・データモデルが変わる） | intent 以降のフルセット | | ② 選ばなかった道がある（「なぜ A でなく B か」が問われる） | 設計判断 | | ③ 原因が非自明で、同じ場所が再発しうる | 調査結果のみ | | ④ 複数の Unit・複数のリポジトリに跨る | Unit の分解 | 逆に、以下がすべて当てはまるなら軽量レーン: - 原因と修正が 1:1 で、コード内コメント＋チケット番号で「なぜ」が復元できる - 顧客に見える振る舞いが変わらない - 単一リポジトリ・小規模で、他への波及がない 迷ったら「次にここを触る人がコードとチケットだけで復元できるか」を問う。 2 つ目は、名前です。それまでは、すべての作業の入口が intent でした。新しいメンバーが加わったときに「入口は intent です」と言われても、日本人の感覚では分かりにくいはずです。「入口は start です」なら、誰にでも一発で伝わります。intent の名前は変えられないので、start という入口を別に作りました。 3 つ目は、再開です。連休明けや、別の PBI に行って戻ってきたときに、「どこまで終わっていて、次は何をするのか」を教えてくれるスキルが欲しくなりました。ただ、再開用のスキルを別に作ると、またそれを覚える手間が増えます。そこで start が現在のブランチと成果物から状態を判定し、進行中の PBI なら再開モードに切り替わるようにしました。現在地・完了済みの作業・未対応の PR 指摘などをまとめ、次に呼ぶスキルを 1 つだけ示します。割り込みの仕事で PBI を行ったり来たりすることが多かったので、ほかの開発者に一番喜ばれたのが、この再開の機能でした。 4 つ目は、作業環境のセットアップです。作業を始める前には、どのブランチを起点にし、PR をどこへ向けるかを決める必要があります。hotfix なら master から切って master へ、通常の作業なら develop から、リリースブランチが生きていれば場合によってはそこから。 この判断の基準は私の頭の中にあるだけで、develop から修正した後で「それは hotfix にしたかった」と分かり、手戻りになったことが何度かありました。そこで、Jira の記載や、今どのブランチが生きているか、手元のブランチの状況から、作業の起点と PR の向き先を start が導き出し、作業環境を整えるようにしました。 作業を始めるときは、とにかく start を呼べばよい。覚えることを 1 つに絞ったのが、このスキルの一番の価値です。 incident-triage: 原因調査を切り出す 5 月末にスキルを作って運用を始め、バグ修正のチケットもそのスキルで回すようになりました。すると、原因が確定しないままでは話が具体化しないことが、はっきりしてきました。intent を始めると、AI が途中で調査を始めてしまったのです。原因が分からないので、確かめてからでないと方針を立てられない、というわけです。調査で分かったことに応じて、PBI の内容を書き直すことにもなりました。intent の途中に調査が挟まるのは、どうにも収まりが悪く感じました。 そこで、PBI が生まれるまでの流れを整理し直しました。バグ修正のチケットは、自分たちで見つけるものもありますが、大半はユーザーからの「何かが動かない」という問い合わせから始まります。以前は、次のように進めていました。 問い合わせを受けて、仕様なのかバグなのか、何が起きているのかを軽く調べる どうやらバグだと分かったら、PBI を起票する 担当者がそれを取り、あらためて詳しく調査する 担当者に引き継ぐ前提なら、最初の一次調査の段階で PBI の内容を精緻に決めておく方がよいはずです。そう考えて、調査を独立したスキル（incident-triage）として切り出し、intent の前に呼ぶ形にしました。独立させておけば、AI-DLC のフローの中だけでなく、普通の障害対応で調査が必要になったときにも単独で呼べます。ワークショップにはバグ修正の話がなかったので、これはトストア独自の追加です。 調査をスキルにしたかった理由は、もう 1 つあります。調査の質を、担当者によらず揃えたかったのです。私はトストアの立ち上げから関わっていて、2019 年から数えて 7 年以上になります。そのぶん、プロダクトの暗黙の知識が私ひとりに偏っていました。AI の調査結果に「それはおかしい」と疑問を持てるかどうかは、プロダクトに触れてきた年月に大きく左右されます。知識が私に偏ったままでは、調査の質が担当者によって変わってしまいます。 私の知識を、頭の中ごとほかの開発者にインストールすることはできません。ですが、スキルを経由すれば、それを疑似的に再現できます。私の知識が incident-triage に溜まってスキルが育てば、ほかの開発者がそのスキルで調査したときにも、同じ知識が働きます。担当者が変わっても、調査の粒度や観点が揃うはずです。 incident-triage では、コマンドを叩く前に関連する Jira をすべて読ませて、否定済みの仮説を再検証しないようにしています。調査は読み取り専用のコマンドで進めるのが基本で、書き込みが必要なときは人間が確認してから行います。 このスキルには、調査のたびに「見るべき観点」が溜まっていきます。その仕組みは後ほど説明します。 pr: PR 作成の自動化 最初は AI-DLC の本筋ではないと考えて、「PR の概要欄を考えて」と頼み、結果を手でコピーしていました。これが面倒になり、gh CLI を入れて自動化しました。PR を作れるだけでなく、レビューの指摘も AI が直接読み取って、修正を考えられるようになりました。 もう 1 つ、PR を出すタイミングでやっていたのが試験項目書の作成です。試験項目書はスプレッドシートで管理していて、試験の観点を書き込み、そのリンクを PR 本文に手で貼っていました。 スプレッドシートへの記入を AI にやらせることもできましたが、試験の結果がセルに OK / NG と書いてあるだけでは、後から振り返るときのエビデンスとして弱いと感じていました。Notion なら、試験手順を構造化して書けますし、エビデンスも残せます。そこで 8 月に、試験項目書を Notion へ移し、あわせて pr スキルを作り直しました。今は pr スキルが、PR の作成とあわせて Notion に試験項目のページを作り、そのリンクを PR 本文に貼るところまでを一括でこなします。このページは、後で qa-support が試験を進めるときの台本にもなります。 8 月: 起票と試験 pbi-ticket: 調査結果の「持ち回り」問題 incident-triage の調査結果は、最初は investigation.md というファイルでリポジトリにコミットしていました。後から振り返るのに便利だと考えたからです。 ところが、私が調べた件をほかの開発者に振るときに、次の手順が必要でした。 手で PBI を起票して番号を決める feature ブランチを作り、調査メモをコミットする 「そのブランチをチェックアウトして、develop の最新をマージしてから作業して」と伝える 指示するのが面倒なうえ、調査メモの存在を私自身が忘れたり、担当者が気づかずに一から調べ直したりする恐れもありました。これを防ぎたいと考えました。 そこで、調査結果はすべて Jira のチケットに集約し、investigation.md は廃止しました。さらに、AI が考えた内容を人が手で Jira に貼る運用では、量が多いと面倒な部分を省いてしまいがちで、貼る人によって粒度もばらつきました。人手を介さず、AI が直接起票する方が、速くて正確です。 副作用として、AI が詳しく書きすぎて、起票した本人でさえ読み返せないチケットができました。対策として、冒頭に「何が起きているか / 誰が困っているか / どう直すか」の 3 行サマリを置くようにしています。 qa-support: 試験を漏れなくこなす もともとは実装が終わった後、私が個人的に「確認にはどんな試験をすればいい？」と AI に聞いていました。これを自分にも、ほかの開発者にも必ずやらせたいと考えました。どんな項目を提案され、やった結果どうだったのかを、担当者の頭の中だけに置いておくのはよくないからです。 スプレッドシートに記録してはいましたが、人の判断が入ると、意図せず暗黙に項目を削ってしまうことがありました。AI が提案する試験項目は人間より細かく、多岐にわたるので、私自身も含めて、つい「これはやらなくていいか」と省きたくなります。そこで、提案された試験項目をすべてこなすことを、スキルとして強制することにしました。 ただ、これにはトレードオフがあり、ほかの開発者も「確認が大変になった」と実感していました。負担の中心は、細かく多岐にわたる試験項目を、どういうシナリオで実施するかを組み立てる手間です。 簡単な例で言えば、新規作成・編集・削除の 3 つを確認するなら、「作成 → 削除 → もう一度作成 → 編集」ではなく、「作成 → 編集 → 削除」と一続きでやる方が無駄がありません。この程度なら人間でも判断できます。しかし、複数の観点が混ざり、複数の PBI にまたがってくると話が変わります。投稿の試験なら、どの種別の投稿を、どの店舗に、どんな条件で出せば、複数の観点を一度に確認できるか。これを人間が考えるのは大変です。 そこで qa-support では、すべての試験観点をカバーするシナリオを、効率のよい順序で AI が組み立てるようにしました。人間はシナリオを考えなくてよくなります。 シナリオが決まったら、AI が人間の頭を混乱させないよう、「これを実施してください」「次はこれです」と、指示を常に 1 つずつ出します。 もう 1 つ工夫したのが、待ち時間の使い方です。人間が「やりました」と報告すると、AI はログやデータを見て、本当に期待どおりに動いたかを裏取りします。最初はこの裏取りを待ってから次に進んでいましたが、たいていは人間が画面を操作して次の試験を準備する方が遅く、その間に裏取りは終わってしまいます。今は、裏取りはバックグラウンドで進め、フォアグラウンドでは次の試験の準備を人間に案内するようにしています。 共通していたこと 振り返ると、7 月以降に足したスキルは、どれも同じ問題に手を入れていました。人手を介すと、面倒な部分が静かに削られるという問題です。調査結果を Jira に転記するときも、試験項目をこなすときも、人手を介すと、誰も気づかないうちに一部が抜け落ちます。これを避けるために、そうした作業を人手からスキルへ移し、人間は判断だけをする形に寄せていきました。 すべてのスキルに入れた 2 つの仕組み 個々のスキルとは別に、すべてのスキルに共通して入れた仕組みが 2 つあります。どちらも、先に書いたように、スキルのことを何も知らない人でも流れに乗るだけで使えるようにするためのものです。 次に呼ぶスキルを、スキル自身が案内する スキルをばらばらに作っても、どの順番で呼ぶかを覚えるのは大変です。ほかの開発者にとってはもちろん、私にとってもそうでした。最初の頃は、intent の次は user-stories だったか domain-model だったかと、よく混乱していました。 そこでスキルを作るときに、作業が終わったら次に呼ぶスキルを示し、人間に促すよう AI に工夫させました。フローの順番を、スキル自身に説明させるわけです。 スキルの抜粋: 完了時に次のスキルを案内する（intent）## 完了時のアクション Intent ドキュメントが承認・保存されたら、以下を宣言してください： > ✅ Intent の作成が完了しました。 > 次のステップ: /ai-dlc-user-stories を実行して > ユーザーストーリーと受け入れ基準を作成してください。 ただし、スキルからスキルを自動で呼ぶことはあえて避けています。コミットするタイミングなど、立ち止まれる区切りが欲しかったからです。流れは示すけれど、次のスキルは人が明示的に呼ぶ。立ち止まれる場所を残しました。 これで、ほかの開発者への展開がとても楽になりました。start さえ呼んでもらえれば、次々にスキルが案内されます。フローの順番を覚えていなくても、案内に沿って呼んでいけば AI-DLC のフローを再現できます。そのぶん担当者は、AI の質問への回答や、ボットの指摘を採用するかどうかといった判断に頭を使えます。 スキルが自分自身を改善する AI-DLC を回していると、初版のスキルでは足りない点に気づきます。最初は、そのセッションの中で AI に改善点を洗い出させ、スキルを直していました。ただ、それをやるかどうかは人に依存していました。改善すべきかを判断し、AI に直させ、コミットし、どのブランチで管理するかを決める。その判断のひとつひとつが面倒でした。 そして、スキルの設計者は私でも、使うのはほかの開発者です。その手元でうまく動かなかったとき、それをスキルに書き戻すかどうかは、使った人の裁量に任されていました。これをやめたかったのです。 そこで、スキル自体に自己改善の仕組みを入れました。作業中に新しい知見を得たら、その場でスキルに書き戻します。使い込むほど精度が上がり、同じ間違いは繰り返さない。誰が使っても、使った分だけきれいに動くようになります。書き戻した内容は普段のコード変更と同じようにコミットし、PR のレビューを通してから取り込みます。 スキルの抜粋: 書き戻すタイミング（全スキル共通）## なぜ必要か スキルの知見は実行したセッションにしか存在しない。書き戻さなければ セッション終了とともに消え、次に同じ作業をする AI が同じ遠回りをする。 個人メモリに書くのは代替にならない。メモリは個人ごと、スキルはチーム配布なので、 メモリで補うと欠落が他メンバーから見えなくなる。 いつ書き戻すか（トリガー） 「知見を得たら」では判定できない。次の列挙で判定する。 いずれか 1 つでも該当したら書き戻す。 - レビューで指摘を受けて修正した（最も見落としやすい） - スキルの記述に無い経路・症状・分岐を通った - コードの該当箇所を新たに特定した - 予告し損ねた副作用を踏んだ - 論点が決着した（やる / やらないが決まった。再提案を防げる） - スキルの記述が実態とずれていた - 同じ失敗を 2 回した（1 回目は不運、2 回目は仕組みの不備） 一番の狙いは、調査のスキル（incident-triage）でした。書き戻しで得たいものは 2 つあります。 1 つ目は、速さです。調査で新しい知見が出たら、それは必ずスキルに書き戻すべきです。似た調査を次にやるときに、素早く結論にたどり着けるからです。 たとえば、失敗した投稿を自動でやり直す仕組み（リカバリ）が止まってしまった障害がありました。リカバリの仕組みは「処理する前に対象のレコードを消す」作りになっていて、レコードが残っていること自体が、一度も処理されていない証拠でした。ここに気づけば調査は一気に進みますが、気づかなければ、ログやコードを見当違いの方向へ調べ続けることになります。そこで、「消えるはずのものが残っていないか」を、似た障害で最初に当たるべき観点としてスキルに書き戻しました。 2 つ目は、精度です。調査結果を私が読んで、「そんなはずはない」「どこか調べていないところがあるでしょう」「その仕様の理解は間違っている」と指摘することがあります。もう一度コードを洗い直させると、「確かにご指摘のとおりで、調査結果が間違っていました」となる。これは誤診です。原因の見立てが間違ったまま進めば、的外れな PBI ができてしまいます。初動調査にとって、一番まずい事態です。そこで、セッション中に私が棄却した仮説や、訂正した理解も、どんどんスキルに書き戻させています。同じ誤診を繰り返さないためです。こうして書き戻した指摘は、ほかの開発者が調査するときにも働きます。先に触れた「調査の質を担当者によらず揃える」という狙いは、この仕組みで実現しています。 どちらも継続的な改善が欠かせず、それを人の裁量に任せたくありませんでした。ただ、調査に限らず、どのスキルも自己改善した方がフロー全体が便利になっていくと考え、すべてのスキルに入れています。 人間が見るのは設計書、と決めるまで このフローでいちばん踏み込んでいるのは、人間がレビューするのは設計書だけで、実装のレビューは AI に任せるという点です。実装のチェックは AI によるレビューと全項目の動作確認に任せ、人間は仕様に責任を持つ、という役割分担です。 最初からこの方針だったわけではありません。当初は、ほかの開発者が書いた実装コードも、ある程度は読んでいました。けれども、それが儀式になっていると薄々自覚していました。 トストアのコードは Go だけでなく、フロントエンドの Vue.js や TypeScript、Python にまたがっています。そのすべての領域で、AI のレビュー以上の精度で論理的な誤りを指摘するのは簡単ではありません。実感として、私が読んでも気づけない問題を、GitHub 上の Claude のレビューボットや、担当者の手元の review スキルが先に指摘していることがほとんどでした。それを人間が追い直しても、品質の担保にはなりません。 そもそも、今の AI が出力する量のコードを、人間がすべて丹念に読み切るのは現実的ではありません。気になる部分は重点的に見るにしても、隅々までチェックするのは、実装している本人にとっても厳しいはずです。私自身も、すべてを見ているわけではありません。 とはいえ、AI を無条件に信用するわけにはいきませんし、本番で壊れては困ります。そこは動作確認で拾います。qa-support で考えられる範囲の動作確認をすべて行い、人間が画面で動作を確かめ、AI がログやデータの状態まで裏取りします。仕様が正しく、動作確認も通っているなら、実装は合っていると判断しています。 人間だけで試験していた頃は、確かめられるのはほぼ画面の見た目までで、ログも見るべきところを全部見られていたわけではありませんでした。今は画面に加えて、ログやデータの状態まで毎回確かめるので、確認の精度はむしろ上がっています。それでも、性能や、めったに通らないエラーの経路、認可の漏れのようなセキュリティ上の問題まで保証できるわけではありません。そこは今の運用の限界だと認識しています。 そのうえで、私が特に見なければならないのは、「こう動いてほしい」という仕様の部分です。ここにだけは責任を持ちます。 では、実装のレビューは誰が担うのか。トストアでは、PR を出すと GitHub 上の Claude のレビューボットが自動でレビューし、指摘をコメントします。開発者は手元の Claude Code にその指摘を読ませて修正し、対応した内容を PR にコメントで返して、再レビューを依頼します。これを指摘が出なくなるまで繰り返します。私たちはこれを「ボットとのラリー」と呼んでいます。 このラリーを前提に変えたのが、人間のレビュアーをどこでアサインするかです。 普通は「動作確認 → PR 提出（人間をアサイン） → 指摘を修正 → 再度動作確認」 トストアでは「PR 提出（レビュアー未アサイン） → ボットとのラリーが収束 → 動作確認 → 人間をアサイン」 PR を出すと、まず GitHub 上のレビューボットから指摘が返ってきます。この段階では、まだコードが変わるかもしれません。動作確認は最終的なコードでやらなければ意味がないので、ボットとやり取りしている間は、むしろ動作確認すべきではありません。 人間のレビュアーにとっても、これから実装が変わるかもしれない PR を見るのは無駄になりかねません。 そもそも、動作確認を済ませてから PR を出すのは、人間のレビュアーへの礼儀だと私は考えています。ですが、ボットには失礼という概念がありません。 そこで、PR はあえてレビュアー未アサインで出します。レビューボットは動きますが、人間には通知が飛びません。まだ動作確認していない前提で、机上で拾える指摘をボットとのラリーですべて潰し、固まったコードで動作確認をします。ここまで終わった段階で、初めて人間をアサインします。 この時点で、ボットの指摘はすべて収束し、コードは動くことが確かめられています。人間のレビュアーに見てほしいのは、残った一点、方向性や修正内容が仕様としておかしくないかだけです。見る場所が限られるので、負担も減ります。そこにたどり着くまでの経緯は、PR 上のボットと担当者のやり取りを振り返れば、どんな指摘を受け、何を直したかが分かります。動作確認で見つかったバグをどう直したかも、そこに残っています。 「設計書が正しくても、実装が間違うことはあるだろう」と思われるかもしれません。ですが、私たちがこれまでに経験した見落としは、むしろ設計書の側で起きていました。ある用語の定義に、特定の投稿経路がこっそり含まれていなかったのです。ドキュメントは嘘を書いていないのに、承認をすり抜けました。この失敗から、units では対象だけでなく対象外まで、すべてのマス目を埋めさせるようにしています。人間の目は、こうした設計書の穴にこそ向けるべきだと考えています。 いちばんの成果: 設計が「残る」ようになった 感覚的な話になりますが、私の負担は減り、ほかの開発者の自走度も上がりました。スプリントの振り返りなどでは、ほかの開発者から「スキルが全部自動でやってくれるので、だいぶ便利になった」「ここまで AI がやってくれると、開発者の存在意義がなくなるのではと、逆に怖くなるくらい楽になった」という声ももらっています。調査や起票、試験の段取りといった周りの作業をスキルが引き受けるようになったことへの感想です。人間の役割がなくなったわけではなく、判断に集中できるようになった、というのが私の受け止めです。 一方で、はっきり言われているのが、確認（試験）の負担が増えたことです。qa-support の節で書いたとおり、試験項目を漏れなくこなすようにした代償で、シナリオを AI が組むようにしてもなお、人間が画面を操作する手間は残っています。これが、後で触れる試験の自動化に取り組んでいる理由です。 では、数字ではどうか。Jira と git の記録から、導入前（2025 年 10 月〜2026 年 3 月）と導入後（2026 年 6〜9 月）を比べてみました。 指標 導入前 導入後 バグのチケットの説明欄の文字数（中央値） 約 360 字 約 3,800 字 原因に触れているバグのチケット 5 / 25 件 32 / 53 件 直し方の方針が書かれたバグのチケット 0 / 25 件 28 / 53 件 「調査済み・否定された仮説」の節があるバグのチケット 0 / 25 件 13 / 53 件 コミットの件名に PBI 番号が入る割合 ほぼ 0% 96〜99%（8 月以降） テストコードの追加行数 557 行（6 か月） 約 8,000 行（4 か月） バグの起票から、最初の PR がマージされるまでの日数（中央値） 7.6 日 10.9 日 いちばん変わったのは、記録の質です。説明欄が長くなったのは、AI が書くようになったからでもあり、長さそのものに価値があるわけではありません。見てほしいのは中身で、半数ほどのチケットで、原因や直し方の方針、ときには調査して否定した仮説まで書かれるようになりました。ほかの開発者が担当したチケットでも同じように変わっていて、「調査の質を担当者によらず揃える」という狙いにも手応えを感じています。コミットに PBI 番号が入る割合は、規約で決めた結果なので品質の指標ではありませんが、どのコードもどの PBI から来たかを追える状態になったことを示しています。テストの追加行数も大きく増えました（行数であってカバレッジではなく、期間の長さも違う点には注意してください）。 導入後は、バグの起票そのものも増えています（6 か月で 25 件 → 4 か月で 53 件）。数字だけ見るとバグが増えたように見えますが、私の実感は逆です。 以前は、調査しても発生の仕組みをはっきりつかめず、「再現待ち」になることがよくありました。次に再現したときのためにログだけ足しておく、という場当たり的な対処も多かったと思います。原因が分からないままでは、起票もためらいます。中身の詰まっていない PBI を「忘れないように」と積んでいくと、着手の起点がないまま数だけが増え、管理しきれなくなるからです。 今は、設計書やコードコメント、調査スキルのおかげで、そうした「謎のバグ」はずいぶん減ったと感じています。原因の仕組みがはっきりすれば、ためらわずに起票できます。1 つの不具合を調べた結果、同じ仕組みの潜在的なバグがほかの箇所でも見つかり、まとめて起票することもあります。起票が増えたのは、デグレで新しいバグが増えたからではなく、潜んでいた問題が見えるようになり、直すと決められるようになったからだと考えています。数字だけでこれを証明することはできませんが、品質を良くするための準備が整ってきた、というのが私の受け止めです。 一方で、1 件のタスクを片づける速さは、数字の上では上がっていません。起票から最初の PR がマージされるまでの日数は、むしろ少し延びています。件数が少なく、リリースの周期にも左右されるので確かなことは言えませんが、これは私の実感とも合っています。担当者の手が遅くなったのではなく、設計書を真面目に作り、レビューを挟む工程が増えた分、手先でさっと直していた頃より 1 件にかかる時間が延びているのです。 それでも、速くなったと感じている部分が 2 つあります。1 つは、障害調査で原因にたどり着くまでの時間です。もう 1 つは、あるバグが完全に直りきるまでの、全体の時間です。以前は、いったんデグレが起きると、あちこちを直してはまた別の場所が壊れる、もぐら叩きのような状態になりがちで、いつ収束するのか見えないこともありました。試験もかなりきつかった。手戻りが減れば、1 件あたりの作業が延びても、全体としては早く片づきます。ただ、どちらも Jira には比べられる記録が残っていないので、数字では示せません。 なお、導入後のバグ 53 件のうち、過去の修正が原因（デグレ）と特定できたものは 6 件でした。残りの多くは、先に書いたように、もともと潜んでいた問題が表に出たものだと見ています。もっとも、導入前のチケットは説明が短く、同じ数え方ができないので、デグレや障害の件数が減ったかどうかは、正直に言って測れていません。救いは、この 6 件がいずれも、原因となった過去の PBI まで説明欄で特定できていることです。どこから来たデグレなのかをたどれることも、記録が残るようになった効果です。 以前は、自分たちでログを見て原因を予想し、コードを読んで確かめていました。「なぜここにこのコードがあるのか」を知るには、git の考古学が必要でした。退職したメンバーが何年も前に書いたコードは誰も覚えておらず、直すときには常に不安がつきまといました。 今は、どの PBI で、どんな仕様で、何をどう直したかが、設計書としてリポジトリに残っています。4 月以降、設計書が残っている PBI は 31 件になりました。 この状態で、原因にたどり着く速さを支えているのが「逆ポインタ」、直すときの正確さを支えているのが「設計書」です。順に説明します。 逆ポインタ: コードから設計書へ ここで効いてくるのが、コードコメントとコミットメッセージに PBI 番号を書く運用です。 // TM-9190 U1: ... 実は当初、この運用には逆風がありました。社内で使っている GitHub 上のレビューボットから、「コメントにドキュメントへの参照を書くべきではない。陳腐化しやすく、メンテナンスも大変だ」とよく指摘されていたのです。一般論としても、よく言われることだと思います。 考えを変えたのは、incident-triage で調査させた後、AI にインタビューしたときでした。「今回の調査で最も役に立った情報は何か。何があったから早くたどり着けたのか」と聞いたのです。私の予想は「設計書があること」でした。ところが AI の答えは違いました。 設計書は補強材料です。一番効いたのは、コードに書かれていた PBI 番号入りのコメントでした。そこから設計書に飛べました。なければ、もっと回り道していたはずです。 AI の説明によれば、調査は次の順番で進んでいました。まずログの出力などから処理の流れを追いかけ、問題が起きた箇所のコードに突き当たる。そこに書かれたコメントの PBI 番号から設計書に戻り、設計書を補強材料として読むことで、「ここがバグの原因だ」と確信する。私は、最初から設計書を読んで原因にたどり着いているのだと思っていました。実際は、コードから設計書へ戻る入口として、コメントが効いていたのです。 AI の自己申告がそのまま証拠になるわけではありません。ただ、言われてみれば、調査はいつもコードを入口に進んでいて、なるほどと納得できる説明でした。トストアのようにバグ修正が中心のプロダクトでは、調査が速く進むことが何より大事です。そこで、PBI 番号のコメントはむしろ積極的に書く方針に切り替えました。陳腐化のリスクは、review スキルで AI が機械的にチェックすれば抑えられます。人力で頑張っていた頃と比べれば、リスクはずっと小さくなります。今では、PBI 番号入りのコメントは 400 箇所を超えています。 スキルの抜粋: コメントの PBI 番号と設計書の整合を点検する（review）- コードコメント中の PBI 番号・要件ラベル引用と設計書の整合: 変更したコードのコメントが引用する PBI 番号・要件ラベルが、 対応する設計書の記載と乖離していないか。 本 PBI で設計書側の仕様を変更した場合、それを引用する既存コメント （他ファイル含む）に修正漏れがないか。 逆にコードの変更で、引用が実態と合わなくなっていないか。 コードからはコメントの PBI 番号をたどり、コミットからはメッセージの PBI 番号をたどれば、どちらからでも、git の考古学なしに設計書へ素早くたどり着けます。番号が指す設計書は、同じ番号のフォルダにまとめてリポジトリの中に置いているので、チケット管理ツールが変わっても参照先は消えません。原因にたどり着くまでの速さは、この逆ポインタが担っています。 社内の共有会では、「コメントではなく、コミットメッセージに書いて git blame でたどればよいのでは」という質問ももらいました。気になって AI に比べさせてみると、最近触ったコードについては、コミットの履歴からでもほぼ同じ精度で PBI にたどり着けました。差が出たのは、次の 3 点です。 消したコードの経緯は、履歴からはたどれません。「この判定は入れてはいけない」といった情報は、対応する行がもう残っていないので、blame を引く先がありません 1 つのコミットに複数の要件が混ざっていると、どの行がどの要件のためのものかまでは、履歴からは分かりません。コメントなら、要件の番号まで書けます 古いコードには、履歴に PBI 番号がありません。 投稿処理の主要なファイルから等間隔に 97 行を抜き出して blame を引くと、89% が PBI 番号のない数年前のコミットに行き着きました。障害調査では、昔からあった潜在的なバグを踏んで、こうした古いコードに行き当たることが少なくありません。コードそのものは古くても、後の PBI でそばに書き足したコメントなら番号が残ります 設計のレビューでは履歴である程度代わりが利きますが、障害調査では代わりになりませんでした。 最近は、ログにも PBI 番号が出るようになりました。これはスキルで決めた運用ではありません。コードコメントの慣習を見た AI が、自発的にログにも広げ始めたものです。障害調査はログから始まることが多いので、ログから直接設計書へ飛べるのは、思わぬ収穫でした。 設計書: なぜこのコードがあるのかが分かる たどり着いた先の設計書が担っているのは、正確さです。 設計書がなかった頃、私には「絆創膏を貼るようなパッチ修正に近いものが、時々起きていたのではないか」という感覚がありました。正しい仕様や設計の思想が分からないまま直すと、「本当にこの修正で副作用はないのか」という疑念を、なんとなく払拭しきれませんでした。実際、何かを直したら別のところがデグレして、「あのコードはそのために入っていたのか。消してしまったから、この問題が復活したのか」と後から気づくこともありました。 今は、逆ポインタから設計書に飛べば、そのコードがどんな PBI を経て、どんな仕様を前提に書かれたのかが分かります。設計書同士も関連する PBI で紐づいているので、今のコードが何のために、どんな思想で書かれているのか、その全体像を AI がコンテキストとしてつかめます。 設計書から全体像をつかめるようになったことで、AI の判断も次のように変わりました。 全部を総合すると、矛盾なく直すにはこうすればよいはずだ ここを直しても、ほかには影響しないはずだ ここを直したのだから、ほかに影響する可能性が残っている。試験項目にデグレの確認を入れるべきだ なんとなくの不安を抱えたままパッチを当てる気分から、「見えている範囲の仕様は全部理解した。その中で矛盾のない修正ができそうだ」という自信へ。これは AI を使っている私もそうですし、直している AI 自身もそうだと思います。 もちろん、設計書が残っているのは AI-DLC を始めて以降に触った場所だけです。障害には大きく 2 つの型があります。昔からあった潜在的なバグが、何かのきっかけで表に出るもの。そして、最近の修正が別の場所を壊すデグレです。前者は古いコードで起きるので、設計書はまだありません。そこで効くのが、調査スキルと、そばに書き足したコメントの逆ポインタです。後者のデグレは、最近よく触っている場所で起きます。よく触る場所はバグがあるから触るのであり、触るからまたデグレする。バグと修正が同じ場所に集まる構造があります。設計書が残っている範囲は、ちょうどそのよく触る場所と重なっているので、デグレを防ぐうえでは、設計書が最近の分しかなくても十分に効くと考えています。 設計を「強制される」ことの価値 突き詰めると、変わったのは「設計をちゃんとやることを強制されるようになった」という一点だと思います。 これまで場当たり的に済ませていた部分でも、仕様を決めて設計書を残すようになりました。それで見落としが減りましたし、それでも見落としたときは、設計書があるので後から振り返れます。「最初の仕様のここが抜けていた。ならこう直せば、矛盾もデグレも出ないはずだ」と、自信を持って言えるようになりました。 AI の弱点は出力のブレですが、十分なコンテキストが与えられていれば、ブレは収束していきます。設計を頑張ることは、まさにそこに効いていると実感しています。 公式のワークフローと見比べる スキルを自作した理由のところで、トストアで育ったスキルは公式のワークフローの v1 と v2 の間くらいにいる、とお話ししました。ここまでの内容を、v2 のリリースノートと見比べると次のようになります。私自身は v2 を使っていないので、リリースノートから代表的なものを抜き出した比較です。 v2 で加わった考え方 トストアのスキル よくある作業を短い経路で済ませるスコープ start の軽量レーン 既存の要件や資料をワークフローの入力にする Jira や調査結果を intent の入力にする 記録済みの回答を再利用する 調査結果があれば、intent は確認の質問に切り替える コミットとレビュー済みの成果物を対応づける コミットとコードコメントの PBI 番号（逆ポインタ） コンストラクションを自律的に、並行して進める なし（各スキルは人が明示的に呼ぶ） 決めたテスト方針を実装に引き継ぎ、ビルドやテストの失敗から自動で立て直す なし レビュー結果を、確認した時点の成果物とソースに紐づけて残す 一部（判断の日付は設計書に残すが、ソースの状態とは紐づけない） 作業の状態や監査記録を、仕組みとして管理する なし（成果物の有無と git から状態を推定するだけ） 表の下の 4 行は、トストアにはないか、あっても部分的です。なかでも生産性への影響で見て一番大きいのは、コンストラクションを自律的に、並行して進める仕組みです。トストアでは各フェーズの合間に、担当者自身が AI の成果物を確認して承認する区切りを挟んでいるので、そのぶん手間が増え、効率は下がっています。ただ、これはレビューとのトレードオフで、半ば意図してそうしています。コンストラクションでもドメインモデルなどの設計書は残るので、そこを自律的にどんどん進められると、レビューが手薄になる懸念がありました。ユニットを U1・U2・U3 と分けても、U1 を前提に U2 が成り立つものもあり、並行で進めるとレビューが混乱しそうだとも感じていました。公式がそこまで仕組みに組み込んでいるなら一度味見する価値はありそうですが、今は後述する試験の自動化を優先しています。 一方で、表の上の 4 行にある考え方は、トストアでも回しながら自然と取り入れていて、方向性はおおむね合っています。v1 と v2 の中間あたりにいる、という私の感覚どおりの結果でした。自作から始めても、公式と近い方向へ進んできたのは、面白いと感じています。逆に言えば、自己改善の仕組みや逆ポインタは、公式のワークフローを使うチームでも取り入れられるはずです。 これは AI-DLC と呼べるのか ここまで読んで、「それは本来の AI-DLC とは違うのでは」と感じた方もいると思います。私もそう思う部分があります。AI-DLC は本来、ビジネス側の意思決定者も含めたチームがモブで意図を詰め、組織やプロセスごと作り変えていくためのものです。その基準で見ると、トストアのやり方には外れているところがいくつもあります。 ビジネス側が入っていない。 PdM は不在で、仕様は私が決めています。バグ修正なら、期待仕様は既存の仕様と問い合わせからおおむね決まります。ですが、新しい価値をどう作るかという問いには、このやり方は答えていません モブをやめた。 複数の視点で意図を詰める機会を失っています。AI からの質問、昼会や Slack での相談、最後の私の確認で補っているつもりですが、モブの代わりになっているとまでは言えません 対象が小さい。 仕事の大半はバグ修正で、部署をまたいで意図をそろえる必要のある案件はほとんどありません。軽量レーンは設計書を作らないぶん、AI コーディングに近いものです 今の流れに AI を足した面がある。 昼会でのリファインメントや見積もり、定期リリースといった流れは残しました。既存のプロセスに AI を足すだけでは速くならないとよく言われます。1 件あたりの速さが上がっていないという結果は、それと無縁ではないかもしれません 保守の段階にある。 統合を見据えて、大きな作り直しはしない前提です。システムを育て続けることを前提にした AI-DLC とは、置かれた状況からして違います それでも AI-DLC と呼んでいるのは、ワークショップで受け取ったものを、この条件で成り立つ形に変えて持ち帰った結果だからです。ビジネス側や組織まで巻き込む変革は、開発チームだけで決められるものではありません。トストアで変えたのは、開発チームの内側でできる範囲、つまり設計書を拠り所に AI に作業を任せ、人間は判断に回るというところまでです。条件がそろったチームなら、本来の形でやる方がよいと思っています。この記事は、条件がそろわないチームがその中で何を持ち帰れるかの一例として読んでいただければと思います。 これから: 試験を AI が自律的に回す 次に取り組んでいるのは、qa-support と Playwright の組み合わせです。成果の節で触れたとおり、今いちばん大きな負担は確認（試験）の手間です。今は AI がシナリオを組み、人間が 1 つずつ操作していますが、これを AI が自律的に実行・確認し、人の判断が本当に必要なところだけ人に助けを求める形にしたいと考えています。 先日、その手始めとなるスパイクを行いました。トストアの通常投稿と、Excel ファイルによる一括投稿の試験を、人の手を介さずに最後まで実行できました。これをスキルに落とし込み、本格的に運用する話は、また別の機会にお伝えできればと思います。 おわりに PdM 不在・少人数・バグ修正中心という、ワークショップの前提とはかけ離れた条件でも、AI-DLC は形を変えれば回せました。振り返って大事だったと思うのは、次の 4 つです。 変えすぎない。 大変革すべきフェーズでなければ、今の開発の流れは残し、変えるべきところだけを変える 最初から完璧を狙わない。 手で一巡してから、AI にスキルを逆算させた。まず自分だけで使い込み、何も知らない人の視点で型にしてから、チームに広げた 人手を介すと抜け落ちる部分を、AI に任せる。 人間は判断だけに集中する 人間の目は、コードではなく設計書に向ける。 少なくとも、少人数で、不慣れな技術領域も抱えるトストアではそう判断した。きちんと設計して残せば、それが AI の次のインプットになる。1 件の作業は速くならなくても、原因にたどり着きやすくなり、正しい修正を導けるようになる 今では、調査からリリース、試験まで、役割の違うスキルをリレーしながら、一気通貫で AI と進められるようになっています。スキルそのものはトストア専用ですが、作って回した経験は、社内のほかのチームにも共有していきます。この記事も、その試みのひとつです。同じようにチームの事情に合わせて AI-DLC を作り変えようとしている方の参考になれば幸いです。

AI-DLC v2 github.com/awslabs/aidlc-workflows/tree/main #ToBeAWSJrChampions2027

AI-DLC: adaptive workflow steering rules for AI coding agents (5.4k stars) What it does All text below is quoted directly from the project README. >AI-DLC (AI-Driven Development Life Cycle) turns AI coding assistants into structured, verifiable software-delivery workflows. One harness-neutral core runs natively in Claude Code, Kiro CLI, Kiro IDE, Codex CLI, Cursor, opencode, and GitHub Copilot. Why AI-DLC: - 5 phases and 33 stages from initialization through operation - 14 agents: 11 domain experts, 2 reviewers, and an adaptive composer - 11 workflow profiles for features, bug fixes, infrastructure, security, proofs of concept, enterprise delivery, and other common work - Human approval gates and source-bound review evidence - 119-event audit trail plus persistent state, team knowledge, and learned rules - The same deterministic engine across every supported harness >curl -fsSL github.com/awslabs/aidlc-workflows/releases/lates… | sh Repository awslabs/aidlc-workflows Repository stats |Metric|Value| |:-|:-| |Stars|5,371| |Forks|969| |Last release|v2.11.0 (2026-10-08)| |Languages|TypeScript 99.8%, Other 0.2%| |Contributors|78| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|claude: 50, cursoragent: 3, Copilot: 4, codex: 1| |AI co-authored commits|Claude: 50, Cursor: 3, Copilot: 4| Main contributor |Field|Value| |:-|:-| |Name|Arden Packeer| |GitHub|@apackeer| |Commits to this repo|1,229 (top contributor)| |Company / Location|Melbourne, Australia| |Followers|33|