1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Syoitu(Syoitu den)Team CoffeeinKDDIアジャイル開発センター株式会社

AI-DLC V2を導入し、その構成要素を組織に最適化させる

1
Posted at

前書き

AI-DLC V2の仕様、みなさんはもう読まれたでしょうか:relaxed:

2026年7月22日にAI-DLC V2がGAされ、V1の公開からおよそ1年が経過しました。
この間に成熟してきたAIエコシステムに合わせて、様々なアップデートが行われています。

この記事では、AI-DLC V2がV1から何が変わったのか、仕様とフレームワークの構成要素について解説したうえで、自分の組織にどう適用すればいいのか、また思想の部分だけを取り入れたい場合にはどうすればいいのかを解説します:point_up_tone1:

Gemini_Generated_Image_yqmvtvyqmvtvyqmv.png

AI-DLCの基本構造：仕様とフレームワーク

AI-DLCという言葉を聞いたことがある方は多いと思いますが、その中身について曖昧なイメージをお持ちの方も多いのではないでしょうか:thinking:

AI-DLCを大まかに理解するなら、仕様 と、それを実現するための フレームワーク に分けて考えると分かりやすいです。

仕様にはAI-DLC実現したい要件や成功条件などが定義されており、フレームワークはそれを実際の開発プロセスとして実行する仕組みを提供します。

V2の仕様はこちら、フレームワークはこちらを参照してください。

また、AI-DLCは組織ごとの開発プロセスやツールに合わせて拡張・カスタマイズされることを前提としている。そのため、実際の運用は組織によって異なることが多く、同じAI-DLCを採用していてもワークフローやルールにはばらつきが見られる。

こうした実装・運用面の違いが、初心者にとってAI-DLCの全体像を掴みにくくしている一因でもあります。:frowning2::point_up_tone1:

Gemini_Generated_Image_gk2d65gk2d65gk2d.png

AI-DLC V2の構成要素

AI-DLC V2の原則

具体的な変更点に入る前に、V2の仕様が掲げる9つの原則を押さえておきたい。

  • 原則1: 人の判断は機械に蒸留できる — 繰り返される判断パターンを機械実行可能な形にして、地道な負荷を減らす。
  • 原則2: すべての意図は曖昧で始まる — 曖昧さは欠陥ではなく前提。AIは仮定せず、確認質問で詰める。
  • 原則3: 安全ネット付きの自己修正ソルバーとしてのAI — 事後条件に対して自分で検証・修正を繰り返して収束するが、停止条件を超えたらヒトにエスカレートする。
  • 原則4: 3コンパートメントモデル — 各ステージを「何を作るか」「正しいとどう判断するか」「何を学んだか」の3つに分けて定義する。
  • 原則5: 全SDLCステージが2コンパートメント構成に収まる — コーディングだけでなく、要件定義や設計のような創造的なステージにも同じ枠組みが使える。
  • 原則6: 単一ショット圧縮より段階的分解 — 一発で仕上げようとすると条件も探索空間も爆発するので、「スキル」という単位で段階的に分解する。
  • 原則7: ビッグバンではなく安全な段階での自律化 — 組織のガードレールは一度に機械化できないので、わかる範囲から始めて少しずつ自律性を広げる。
  • 原則8: 拡張性 — 追加・上書き・新規ステージ追加の3パターンで、ベースラインと同じ土俵でワークフローを拡張できる。
  • 原則9: 実践から学ぶ — 人の修正やその場対応を、検証ルールへの昇格候補として学習し続ける。

とくに原則1・7・9は、後述する学習ループや自律開発モードといったv2の目玉機能に直結しています。先に原則を頭に入れておくと、この後紹介する5つの変更点が「なぜそうなっているか」まで含めて理解しやすくなります。

V2で何が変わったのか

v2で変わった点は、大きく5つあります。

  1. AI-DLCのコンテキストをcore/、コーディングエージェント向けの薄い実装をharness/に分ける構造へ変更
  2. 5フェーズ・32ステージへのワークフロー再編
  3. 役割ごとに分かれた14種類のエージェント編成
  4. プロジェクトの性格に応じて実行ステージ数を変える「スコープ」という軸
  5. ステージ実行中の判断が自動でルールとして積み上がっていく学習ループと、状態・監査の仕組み

背景にあるのは、チームごとに違う配信フローに合わせられる、粒度の細かいビルディングブロックへの需要と、スキルやマルチエージェントランタイムの基盤によるプラットフォーム成熟度という2つで、どちらもこの1年で揃った。

V1では各ステップで人間の承認を求めるような設計思想だったが、V2ではなるべく人間の介入を減らし、自律へ持っていくことを進めています。

Gemini_Generated_Image_4kgim94kgim94kgi.png

1. コアとハーネスを分離する設計

フレームワークの修正です。

v1の時、ユーザーがGithubリポジトリで配布されるai-dlc-rules-v<release-number>.zipから、core-workflow.mdをKiroなら.kiro/steering/、Claude CodeならCLAUDE.mdというように各コーディングエージェントの規約に合わせて自分でコピー配置する運用でした。

v2ではAI-DLCコンテキストファイルをcore/に置き、Claude Code・Kiroなどに それぞれの実装（マニフェストやスキルなど）をharness/側に持たせます。

ビルドスクリプトがこの2つを合成してdist/<harness>/を生成する、つまり「ロジックを1箇所で直せば、対応する全ハーネスの配布物が生成し直される」という構造です。

2. 5フェーズ・32ステージへの再編

v2のワークフローは5フェーズ・32ステージに整理されています。
ステージとは、1つの成果物を作成し、承認を通過するための最小単位の作業を指します。

たとえば、あるステージではユーザーストーリーを入力として受け取り、ドメインモデルを出力として生成します。この成果物（ドメインモデル）をユーザーがレビューし、承認を通過することで、次のステージへと進みます。

フェーズ ステージ数 主な内容
0. Initialization(New) 3 ワークスペーススキャフォールド／検出／状態初期化。1回の呼び出しで完結
1. Ideation(New) 7 意図の把握、市場調査、実現可能性、スコープ決定、チーム編成、簡易モックアップ、承認
2. Inception 8 既存コード解析、プラクティス発見、要件分析、ユーザーストーリー、詳細モックアップ、アプリケーション設計、Unit分割、デリバリー計画
3. Construction 7 機能設計・NFR要件・NFR設計・インフラ設計・Unit単位のコード生成・ビルド/テスト・CIパイプライン
4. Operation 7 デプロイパイプライン、環境プロビジョニング、デプロイ実行、可観測性、インシデント対応、性能検証、フィードバック（Ideationへ回帰）

v1はどうだったか

v1は、次の3フェーズ構成でした。
ステージ数はv2のように固定されておらず、フェーズごとに性質が大きく異なっていました。

  • Inception（7ステージ）: ワークスペース検出、逆行分析、要件分析、ユーザーストーリー、ワークフロー計画、アプリケーション設計、Unit生成
  • Construction（Unit数に応じて可変）: Unitごとに「機能設計→NFR要件→NFR設計→インフラ設計→コード生成」という最大5ステージをループする構造で、Unitが増えるほどステージ数も増えていきました
  • Operations（実質プレースホルダー）: 実装がなく、ビルド・テストまでを実質Constructionフェーズが肩代わりしていました

Gemini_Generated_Image_b0q4hub0q4hub0q4.png

Unitとは、システムを分解した開発単位のことです。
マイクロサービスなら1サービス、モノリスなら論理的なモジュールのまとまりに対応し、いくつに分けるかはプロジェクトごとに異なります。

Inceptionの「Unit分割」ステージでこの数が決まり、Constructionではこの数だけ「機能設計→NFR要件→NFR設計→インフラ設計→コード生成」のループが回ります。

3. 14人のエージェント編成

v2最大の特徴が、役割ごとに分かれた14種類のエージェントだ。
ドメインエキスパート11体、レビュー専任2体、Composer 1体の3グループに分かれる。

① 11体のドメインエキスパート

Product / Design / Delivery / Architect / AWS Platform / Compliance / DevSecOps / Developer / Quality / Pipeline-Deploy / Operations の11体。

狭く深い専門職の集まりではなく、広く浅い少人数モブという設計思想で作られている。

  • 例外は Architect だけで、3フェーズ・9ステージにまたがる別格の守備範囲を持つ。

② レビュー専任の2体

Product Lead Agent と Architecture Reviewer Agent、自分では成果物を作らない。

  • 他のエージェントの成果物に「READY」か「NOT-READY」かの判定だけを## Reviewとして追記する
  • NOT-READYの場合、既定で最大2回まで自己修正ループを回す
  • それでも直らなければ最終判断は人間に投げる

③ Composer Agent（1体）

/aidlc composeで呼び出される特殊枠。
既存のスコープに当てはまらないタスクに対して、実行・スキップを含むステージプランをその場で提案する。

2つのティア: judgment / templated

エージェントは実行時のコストと精度のバランスを取るため、judgmentとtemplatedという2つのティアにも分かれている。

ティア 該当エージェント（8体 / 3体） 特徴
judgment Product・Design・Developer・Quality・DevSecOps・Compliance・AWS Platform・Architect セッションのモデル・reasoning effortをそのまま継承
templated Delivery・Pipeline-Deploy・Operations 軽量モデルで定型作業をこなす

Gemini_Generated_Image_khbcd4khbcd4khbc.png

4. スコープ・深さ・テスト戦略という3軸

32ステージ全部を毎回回すわけではない。
プロジェクトの性格に応じて「スコープ」を選ぶことで、実行するステージ数と深さが変わる。

スコープ 実行ステージ 深さ
enterprise 32/32 Comprehensive
feature（デフォルト） 32/32 Standard
mvp 22/32 Standard
workshop 25/32（Ideation全スキップ） Standard depth / Minimal test
bugfix 7/32 Minimal

これ以外にもsecurity-patch・refactor・pocはMinimal寄りの軽い設定で、infraだけはスタンダード深さの13/32ステージとやや厚めになっている。

深さとは別に「テスト戦略」という軸もMinimal/Standard/Comprehensiveの3段階で独立して選べる。ミニマムのテスト戦略は「Nyquistモデル」と呼ばれ、要件1つにつきテスト1本、ユニットテストのみで5〜15本程度に絞る割り切った設計だ。

スコープは自由記述の依頼文からキーワードで自動判定されるが、既存スコープに当てはまらない場合や、判定に自信が持てない場合（スコープを示すキーワードと5語を超える説明文が同時に出てきたときなど）は、コンポーザーによるcompose提案に自動的に切り替わる。ワークフロー実行中に「市場調査は飛ばせる？」のような雑談から、残りステージだけを組み直すこともできます。

5. ルール & 学習ループ、知識体系、状態・監査ログ

ルールはorg.md → team.md → project.md → phases/<phase>.mdという階層のMarkdownに積み上がっていく。ステージ実行中の解釈・逸脱・トレードオフはmemory.mdという日誌に自動で書き溜められ、ユーザー承認したうえで採用されたものはproject.mdに追加されます。

知識体系は2層に分かれていて、フレームワーク側が最初から持っている知識とチームが運用しながら育てるチーム知識を分離している。

読み込み順はルール、共有知識（フレームワーク側）、エージェント別知識（フレームワーク側）、チーム共有知識、エージェント別チーム知識、過去の成果物、という並びです。

最後は状態管理と監査ログについて。

進捗は、実装ごとに生成されるaidlc-state.mdという単一のファイルに6種類のチェックボックス状態（[ ]未着手 / [-]進行中 / [?]承認待ち / [R]修正中 / [x]完了 / [S]スキップ）で持ち、エンジンはセッション開始のたびにこのファイルを読んで続きを判断する。加えてaudit/配下には74種類・19カテゴリのイベントが追記型で記録される。

中断から再開するときは、チェックポイントから再開するか、現在のステージをやり直すか、指定ステージへジャンプするか、新しい意図として最初からやるか、という4択が出てくる。

AI-DLC V2 フレームワークの使い方

ここまでは仕様寄りの話だったので、ここからは実際にClaude Codeでv2フレームワーク（aidlc-workflows）を動かすときの手順を、ハンズオン形式で紹介します。

使うプロジェクトは新規に作成するNext.jsプロジェクトで、直接cloneしてきたaidlc-workflowsリポジトリの中で初期化します。

執筆時点では、v2ブランチにV2の内容が入っているため、まずブランチの切り替えを行う必要があります。(2026/7/24)

Next.jsプロジェクトを初期化します。

aidlc-workflows % npx create-next-app@latest my-app --yes

1. Claude Codeに導入する

フレームワークのリポジトリには、Claude Code・Kiroなど各ハーネス向けにビルド済みの配布物がdist/<harness>/配下に入っている。Claude Codeの場合、自分のプロジェクトへdist/claude/の中身をコピーするだけで導入が終わる。

aidlc-workflows %　cp -r dist/claude/.claude/ my-app/.claude/
aidlc-workflows %　cp -r dist/claude/aidlc/   my-app/aidlc/   # .claude/とは別に、プロジェクト直下に並べて置く
aidlc-workflows %　code my-app

.claude/側にはエンジン本体（スキル・14エージェント・ツール・13個のフック）が、aidlc/側には各ワークフローの成果物や状態、チームナレッジが溜まっていく「ワークスペースシェル」が入ってます。

aidlc/spaces/default/memory/にはあらかじめ枠だけ用意された知識ツリーが入っており、これが無いと後述の--doctorが失敗します。

AWSアカウントを使わない場合の注意点

配布される.claude/settings.jsonはデフォルトでAmazon Bedrock（us-east-1）向けの設定になっているため、AWS認証情報を通しておく必要があります。

Bedrockを使わないなら、envから以下を削除する。

.claude/settings.json
   "env": {
-    "AWS_AIDLC_DEFAULT_SCOPE": "workshop",
-    "CLAUDE_CODE_USE_BEDROCK": "1",
-    "AWS_REGION": "us-east-1",
-    "ANTHROPIC_DEFAULT_FABLE_MODEL": "global.anthropic.claude-fable-5[1m]",
-    "ANTHROPIC_DEFAULT_OPUS_MODEL": "global.anthropic.claude-opus-4-8[1m]",
-    "ANTHROPIC_DEFAULT_SONNET_MODEL": "global.anthropic.claude-sonnet-4-6[1m]",
-    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "global.anthropic.claude-haiku-4-5-20251001-v1:0"
+    "AWS_AIDLC_DEFAULT_SCOPE": "workshop"
   },
-  "model": "opus[1m]",
   "effortLevel": "xhigh",

これで通常のClaude Code認証で動作する。

2. ヘルスチェックする

Claude Codeのセッションに入ったら、いきなりワークフローを始めずに--doctorでセットアップを検証するのが最初の一手です。

/aidlc --doctor

bunが使えるか、13個のフックがすべて配置されているか、aidlc-state.mdと監査ログに矛盾がないか、32ステージのステートグラフに循環がないか、9つのスコープすべてがグラフ上を破綻なく歩けるか、といった項目を機械的にチェックし、exit code0/1で合否を返す。正常なら次のような出力になります。

07E8A0EB-3E68-45E5-BF4B-6228FD48CFDF.jpeg

3. ワークフローを始める

/aidlcのあとに自由文で「何を作りたいか」を書くと、スコープが自動判定されてワークフローが始まる。

/aidlc Build a REST API for inventory management

セッション開始時にはaidlc/spaces/default/intents/<日付>-<ラベル>/という記録用ディレクトリが自動で作られ、最後にスコープの確認がきます。

AD114505-C5E8-4849-83E7-B6B47C8D704B.jpeg

今回は新規機能を追加したいので、通常のfeatureにします。

bugfix・feature・mvp・security-patchの4つはさらに専用のショートカットコマンド（/aidlc-bugfixなど）も用意されていて、/aidlc-bugfixは/aidlc --scope bugfixと完全に同じ動きをする。

/aidlc bugfix
/aidlc bugfix Fix the login timeout issue

4. Ideationフェーズ — 3つの対話モードで進める

Initializationが終わるとIdeationフェーズに入り、ここから各ステージに承認ゲートが付く。
最初のステージ（Intent Capture、担当はaidlc-product-agent）では、質問への答え方を3つから選べる。

A3A12B86-207A-4448-B875-9590457E96B8.jpeg

  • Guide Me: 構造化された質問に1つずつ答えていく
  • Edit File: 成果物のMarkdownを直接編集する
  • Chat: 雑談ベースで話し、AIが決定事項を抜き出す

ステージの途中でモードを切り替えることもできる。ここはガイドしてもらうを選びましょう、そしてビジネス観点で色々と聞いてきます、任意に選びます。

EF35B70F-1F4C-4C05-B743-4ECE09B3B62F.jpeg

その後はシステム要件も聞いてきます。

FB5B1710-5D4F-4C24-80E9-480FF4DB2F9F.jpeg

その後、学びについても聞いてきます、今回はあえて日本語で会話するように指示出したので、それを学びにするか、提案してきました。

9FC4789F-FBA0-41F0-86FD-89DBEBED9338.jpeg

ステージの成果物ができると、承認が出ます。

1477864D-DBD6-466D-B56C-EE50ACE707C1.jpeg

Approveを選ぶとProgress: 4/32 overall | 1/7 IDEATION stages complete.のように全体進捗が更新され、次のステージ（Market Research → Feasibility & Constraints → Scope Definition → Team Formation → Rough Mockups → Approval & Handoff）へ進みます。

スコープによっては一部のステージが条件付きで自動スキップされます。

実際にはIdeationだけでもあと6ステージ残っていますが、1ステージずつ書き起こすと長くなりすぎるため、実況はここでいったん止めます。押さえておいてほしいのは、どのステージも今回のIntent Captureと同じ流れ——

  • 対話モードを選ぶ
  • 質問に答える
  • 学びを聞かれる
  • 承認ゲートを通る

——を繰り返しているだけ、という点です。

「学びを聞かれる」がv2の肝

この部分こそ、v2で一番効いている変化だと思います。v1では「毎回同じ確認をされる」という不満が消えませんでした。

v2では仕組みが違います。

  1. ステージ実行中の解釈・逸脱・トレードオフを、日誌に自動で書き溜める
  2. 承認ゲートの直前に「次回のために残しておきたい指摘はあるか」を聞く（=学びの選択）
  3. 採用された指摘はproject.mdに定着し、次回以降のワークフロー開始時点から全エージェントに読み込まれる恒久的なルールになる
  4. ワンクリックでteam.mdにも昇格できる

ドキュメント内の例で言うと、あるプロダクトエージェントが「トランザクション」をDBのトランザクションと誤解していたのを、実は決済取引のことだと一度訂正すれば、以降のワークフローでは二度とその誤解は起きません。

「コストは一度だけ払えばよく、以降のすべてのワークフローでその投資が回収される」という説明は、まさにこの仕組みを言い表しています:relaxed::point_up_tone1:

5. 状況確認・やり直し・中断からの再開

進行中のワークフローを壊さずに状況だけ見たいときは--status、途中のステージだけ単発で試したいときは--stage <slug> --single、フェーズ単位で飛びたいときは--phase <name>が使える。

/aidlc --status
/aidlc --stage code-generation --single
/aidlc --phase construction

セッションを閉じてしまっても、/aidlcとだけ打てばaidlc-state.mdを読んで続きから再開する。中断のタイミングによっては「チェックポイントから再開する」「現在のステージをやり直す」「指定ステージへジャンプする」「新しい意図として最初からやり直す」の4択が出てくる。

AI-DLCとの向き不向き

生成される要素など、小さい規模のプロジェクトとのトレードオフ

正直に言うと、32ステージ・14エージェント・72種類の監査イベント・複数階層のルールファイルという構成は、個人の書き捨てスクリプトや週末ハッカソンには明らかにオーバーヘッドです。

一応V2では、「スコープ」という逃げ道は用意されていますが

公式ドキュメントにあるworkshopスコープの説明に向き不向きの線引きとして分かりやすい説明を書いてます。

次のようなケースには明確に不向きだと明記されている。

  • 一人での作業
  • その場のノリで始まる並行作業
  • Boltを取ったまま引き継がずに離脱してしまう可能性がある場合

つまりAI-DLCはチーム向けのフレームワークであり、そこを飛ばしたいだけの人には最初から別の選択肢を選ぶべき、というのが公式のスタンスに近い。

OpenspecでAI-DLCを実践する

ここまで見てきた通り、AI-DLCの本体はかなり重厚な仕組みです。

だが公式が「Methodology first. AI-DLC is fundamentally a methodology, not a tool.」と明言している通り、AI-DLCが大事にしているのは「要件定義→設計→承認→実装という順序を守り、各ステップで人間が明示的にYes/Noを言う」「一度した指摘は二度とさせない」という思想そのものであって、32ステージや14エージェントという実装はその1つの表現に過ぎない。

この思想だけを、もっと軽い道具で再現するという選択肢もあります。

OpenSpecは「提案（proposal）→ デザイン(design) -> 仕様（spec）→タスク(tasks)→アーカイブ(archive)」という薄いスペック駆動開発のワークフローを、markdownの規約だけで実現するツールです。

AI-DLCのInception〜Constructionの骨格、つまり「コードを書く前に仕様に承認を得る」という部分だけを抜き出したような立ち位置で、14種類のエージェント編成や72種類の監査イベントは持たない代わりに導入コストがずっと低い。

ただ、学習ループの部分はOpenSpecに存在しません:point_up_tone2:
openspec/config.yamlにcontextとrulesを書いておくと、それが毎回プロンプトに注入される仕組みは用意されています。

# openspec/config.yaml
schema: spec-driven

context: |
  ドメイン用語: 「トランザクション」は決済取引を指す。DBのトランザクションではない。
  Tech stack: TypeScript, React, Node.js, ClickHouse

rules:
  proposal:
    - ロールバック手順を明記する
    - 影響を受けるチームを明記する
  specs:
    - Given/When/Then形式で書く
    - 既存パターンを参照してから新規に定義する

contextは全アーティファクト（proposal/design/specs/tasks）の生成プロンプトに常に差し込まれ、rulesはアーティファクトごとに指定できる。つまり一度の指摘を、ここに1行書いておけば以降ずっと同じ誤解を防げる、という点だけ見ればAI-DLCのproject.mdと同じ効果を狙える。

ただし中身は別物で、AI-DLCの学習ループが「自動収集→都度確認→ワンクリック昇格」なのに対し、OpenSpecのconfig.yamlは「気づいた人が手で書く」静的な設定ファイルに過ぎません。

観点 AI-DLC v2（学習ループ） OpenSpec（config.yaml）
記録のきっかけ 各承認ゲートの直前に「次回のために残したい指摘はあるか」と自動で聞かれる 誰かが指摘に気づいたときに、手動でcontext/rulesを編集する
保存先と伝播範囲 project.mdに定着、ワンクリックでteam.mdに昇格し他プロジェクトにも展開できる プロジェクトのopenspec/config.yamlのみ。他リポジトリへの共有はgit運用任せ
反映タイミング ワークフロー開始時に一度だけコンパイルされ、実行中のワークフローには遡って反映されない 次にopenspec instructions <artifact>を呼んだ瞬間から反映される。実行中のセッションでも次のコマンドから効く
無限ループ対策 同じステージで3回以上「Request Changes」すると「そのまま確定」の選択肢が出るエスケープハッチがある 相当する仕組みはない。ルール化しない限り、何度でも同じ指摘が起こり得る
収集の自動化 ステージ実行中の解釈・逸脱・トレードオフを自動で日誌に書き溜める 自動収集はない。書くかどうか・いつ書くかは完全に人間任せ

要するに、OpenSpecは「一度書けば毎回効く」という入れ物こそ持っているが、「指摘を自動で拾い上げてその入れ物に詰める」部分はAI-DLCのように仕組み化されておらず、運用でカバーする必要があります。

エージェント編成をフレームワークに丸ごと委ねたいわけではなく、設計と承認のプロセスさえ型にはめられれば十分、というチームには相性がいい。

どちらを選ぶかは、結局「エージェント編成やルールの階層構造をフレームワークに任せたいか、自分たちで薄く持ちたいか」という判断によります。

エンタープライズ開発や、複数チームが並行して開発するような規模ならAI-DLC v2をそのまま使う価値は大きいですが、数人のチームで「設計してから実装する」という規律さえ守れれば十分な場合は、OpenSpecで思想だけを移植したほうが、ドキュメントの海に溺れず済みます。

最後に

AI-DLCの本体は仕様の思想であり、ワークフローはその思想を具体化した一形態にすぎません。

導入を検討するなら、いきなりフル装備を試すのではなく、まずはpocやbugfixのような軽いスコープで承認ゲートと学習ループの手触りを確認してから、自分のプロジェクトの規模と規律に見合うスコープに調整するか、あるいはOpenSpecのような軽量な代替に切り替えるかを判断するのがいいと思います。

もしくは、仕様の思想そのものを理解したうえで、独自のワークフローを組み立てるのもおすすめです。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?