AI-DLC Workflow V2のインストール: cpコピーからインストールスクリプトへ
「前に入れたときは、リポジトリを clone して `dist/` を手でコピーして…」。そんな手順を覚えている人も多いのではないでしょうか。AI-DLC Workflow V2（以降V2）の 2.8.1 では導入がぐっと簡単になりました。インストールスクリプトで `aidlc` コマンドを入れて、その `aidlc` で設定するだけの2段階です。bun も Node.js も要りません。どれだけ手軽になったのかを、順に見ていきましょう。シリーズ第26回。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 26AI-DLC Workflow V2のインストール: cpコピーからインストールスクリプトへ This article
1. はじめに
この記事はV2解説シリーズの第26回です。V2は、AI-DLC（AI-Driven Development Life Cycle）を各コーディングエージェント上で動かす実装です。
V2 の 2.8.1 では、インストールスクリプトが用意され、導入方法が変わりました。以前は、リポジトリを取得してビルド済みの配布物（ハーネスごとの
dist/<harness>/ ディレクトリ）を cp で自分のプロジェクトへ手でコピーする方式でした。この方式ではエンジンを bun で動かす前提でした。2.8.1 では、まずインストールスクリプトで
aidlc という専用コマンドをマシンに入れ、そのあと aidlc コマンドでプロジェクトを設定します。導入が「スクリプトでコマンドを入れる段階」と「そのコマンドで設定する段階」の2つに整理されたわけです。この記事を読み終えると、インストールスクリプトで
aidlc を導入し、プロジェクトを設定し、導入完了を自分で確認し、更新やバージョン固定まで扱えるようになります。従来の手動コピー方式と何が変わったのかも整理します。なお、記事内のバージョン表記は「2.8.1」で統一します。導入コマンドは特定の版に依存せず最新の安定版を入れる書き方（
releases/latest）を使います。2. 前提条件
では、導入の前に必要なものを見ていきましょう。
対応OS/アーキテクチャ
リリース資産は次の環境を対象にしています。
- macOS x64 / arm64
- Linux x64 / arm64（glibc ビルドと musl ビルド）
- Windows x64
インストールは対象ユーザーとして実行します。Unix のインストーラーは root での実行を拒否し、Windows のインストーラーは管理者に昇格したセッションでの実行を拒否します。ネイティブのインストールはユーザーごとに行われ、
sudo は不要です。必要なツール
オンラインでの実行には
curl または wget が必要です。すべての実行で sha256sum または shasum が必要です。GitHub CLI（gh）は任意で、リリースが必要とする署名検証のフラグに対応している場合にのみ使われます。GitHub CLI が無い、または古い場合でもインストール自体は止まりません（その場合は署名検証がスキップされ、チェックサム検証は必須のまま残ります）。bun / Node.js は不要
インストールされる
aidlc コマンドと設定処理は、bun や Node.js を必要としません。この点は一次資料で確認できます（README に "Bun and Node.js are not required"、guide/18-install-and-lifecycle.md に "do not require Bun or Node.js" と記載）。「エンジンは TypeScript なのに bun がいらないのか」と疑問に思うかもしれません。インストールスクリプトで入るのは、ランタイムを内包した自己完結型の
aidlc バイナリです。プロジェクトのフックも、この aidlc バイナリ経由で動きます。したがって別途 bun や Node.js を用意する必要はありません。一方、手でファイルをコピーする方式で使うビルド済み配布物（dist/<harness>/）は bun を呼び出す形なので、そちらではフックの実行に bun が必要でした。ここが、旧来の手動コピー方式と新方式の実行基盤の違いです。Alpine Linux（musl）での事前準備
Alpine Linux の musl 環境だけは、システムライブラリの追加が必要です。インストールされる
aidlc バイナリの musl ビルドは、Node.js と同じく、システムの libgcc と libstdc++ パッケージを前提とします（別途 bun を入れる必要があるという意味ではありません。バイナリはランタイムを内包しており、そのランタイムが依存するシステムライブラリという位置づけです）。インストーラーやバイナリを実行する前に次を実行しておきます。1
apk add libgcc libstdc++この前提は x64・arm64 いずれの Alpine システムにも当てはまります。インストーラー自体は
apk を実行しませんが、対応するローダーの失敗を検出したときに上記のコマンドを表示します。3. 第1段階：インストールスクリプトによる導入
まず、
aidlc コマンドをマシンに導入していきましょう。ここが1段階目です。macOS / Linux / WSL
スクリプトを一時ディレクトリへダウンロードしてから実行します。実行後は一時ファイルを片付けます。
1
2
3
4
5
6
7
tmp="$(mktemp -d)"
curl -fsSL \
https://github.com/awslabs/aidlc-workflows/releases/latest/download/install.sh \
-o "$tmp/install.sh"
sh "$tmp/install.sh"
rm -rf "$tmp"
export PATH="$HOME/.local/bin:$PATH"このインストールスクリプト方式では、
claude、kiro、kiro-ide、codex、opencode のハーネスランタイムがまとめて入ります。インストール時にハーネスを尋ねる質問はありません。Windows PowerShell
Windows でも対等に、
install.ps1 を一時ディレクトリへ取得して実行します。1
2
3
4
5
6
7
8
$download = Join-Path $env:TEMP "aidlc-install-$PID"
New-Item -ItemType Directory -Force $download | Out-Null
$installer = Join-Path $download install.ps1
Invoke-WebRequest `
-Uri https://github.com/awslabs/aidlc-workflows/releases/latest/download/install.ps1 `
-OutFile $installer
& $installer
Remove-Item -Recurse -Force $downloadインストール先
インストール先は次のとおりです。
- Unix: バージョンは
~/.local/share/aidlc/versions/配下に入り、~/.local/bin/aidlcが有効なバージョンへリンクされます（既定） - Windows: バージョンは
%LOCALAPPDATA%\aidlc\versions\配下に入り、%LOCALAPPDATA%\aidlc\bin\aidlc.cmdという安定したシムが保たれます
PATH が通らない場合
aidlc が見つからないときは、次のいずれかで対処します。- インストーラーが表示する PATH の案内に従う
- 新しいシェルを開き直す
- Unix では
export PATH="$HOME/.local/bin:$PATH"を実行する（恒久化する場合はシェルの起動ファイルに追記する）
Unix のインストーラーは、
--profile <$HOME 配下の絶対パス> を明示しない限りシェルの起動ファイルを編集しません。Windows のインストーラーは現在の PowerShell プロセスへ bin ディレクトリを追加し、新しいセッションで必要なコマンドを表示しますが、PowerShell プロファイルは編集しません。4. 第2段階：aidlc コマンドによる設定
aidlc が入ったら、次はプロジェクトを設定していきましょう。ここが2段階目です。ハーネスを選んで設定する
プロジェクトのルートに移動し、使うハーネスを指定して設定します。
1
2
3
cd your-project
aidlc config --harness kiro
aidlc doctor--harness に渡せる名前は kiro、kiro-ide、claude、codex、cursor、opencode、copilot です（この例では Kiro CLI を使う kiro を指定しています）。ターミナルが利用できる状態で --harness を付けずに aidlc config を実行すると、対話式のセットアップが始まります。aidlc config はローカルのみで完結し、トランザクショナルに動きます。選択したハーネスのツリー、aidlc/ ワークスペースシェル、ルート統合、プロジェクションスタンプ、オーナーシップの基準を作成します。ワークフローのインテントは作りません。起動する
設定が済んだら、そのプロジェクトのルートでハーネスのチャットを起動します。「ハーネスを開く」とは、使っているコーディングエージェントのセッションを開始することです。起動コマンドはハーネスごとに異なります。
- Kiro CLI:
kiro-cli chat - Claude Code:
claude - Codex CLI:
codex - opencode:
opencode - Kiro IDE / Cursor: プロジェクトをそのエディタで開く（Cursor は
agentでも起動できます） - GitHub Copilot: Copilot CLI または VS Code
セッションが開いたら、作業内容を説明してワークフローを始めます。ここでは Kiro CLI を例にします。
1
2
cd your-project
kiro-cli chatチャットが開いたら、次のように入力します。
1
/aidlc 在庫管理のREST APIを作るCodex CLI では
/aidlc の代わりに $aidlc を使います。V2 は要求からワークフローを選び、足りない判断を尋ね、承認ゲートで止まって人間の判断を待ちます。5. 動作確認
続いて、導入が正しく完了したかを自分で確かめていきましょう。
まず、コマンドが認識されているかを確認します。
1
aidlc --versionインストールしたバージョン（2.8.1）が表示されれば、
aidlc コマンドは正しく PATH 上にあります。次に、プロジェクトのルートで自己診断を実行します。
1
aidlc doctoraidlc doctor は Machine（マシン）、Project（プロジェクト）、Framework（フレームワーク）の整合性チェックを行い、結果を報告します。警告は助言的で終了コード0のまま、いずれかのチェックが失敗すると終了コード1になります。失敗した行や警告の行は表示され、健全な行は既定で折りたたまれます。すべての行が健全であれば、導入は完了しています。ハーネスを開いたあとは、そのハーネス内から
/aidlc --doctor（Codex CLI では $aidlc --doctor）でも同じ診断を確認できます。6. 従来手順（cp 方式）からの変更点
ここで、旧手順との違いを整理しましょう。
従来の手動コピー方式では、リポジトリを取得し、ビルド済みの配布物（ハーネスごとの
dist/<harness>/ ディレクトリ）を cp で自分のプロジェクトへコピーしていました。このシリーズでも、第2回「Kiro CLIで始めるQuick Start」では dist/kiro/ を、第3回「Claude Codeで始めるQuick Start」では dist/claude/ を、それぞれ cp でコピーする手順を紹介していました。いずれもエンジンを bun で動かす前提でした。2.8.1 の新方式では、この2つの記事の手順が変わります。対比すると次のようになります。
| 観点 | 従来（手動コピー方式） | 2.8.1（インストールスクリプト方式） |
|---|---|---|
| 導入の起点 | リポジトリやリリースから配布物を取得 | インストールスクリプトで aidlc コマンドを導入 |
| プロジェクトへの反映 | cp で dist/<harness>/ をコピー | aidlc config --harness <name> が設定を適用 |
| ランタイム | bun 前提（dist/ は bun を呼び出す） | bun / Node.js 不要（自己完結型の aidlc バイナリ） |
| 更新・バージョン管理 | 取得とコピーをやり直す | aidlc update / aidlc use / aidlc config --pin |
手動でファイルを管理したい場合の道も残っています。対応する
aidlc コマンドを入れたうえで、リリースから aidlc-runtime-X.Y.Z.tar.gz を取得し、runtime/<harness>/ をプロジェクトへコピーする方式です。ただし、同じランタイムをトランザクショナルに適用し、後の更新に向けてオーナーシップも記録する aidlc config の利用が勧められています。7. アップグレードとバージョン管理
導入できたら、更新とバージョンの扱いも押さえておきましょう。
更新する
最新へ更新するには
aidlc update を実行します。更新の有無だけを確認したいときは aidlc update --check を使います。aidlc update --check は更新メタデータを取得するだけで、インストールは行いません（更新がある場合は終了コード5、最新なら0、確認不能・オフラインなら3、チェックが無効なら1を返します）。1
2
aidlc update
aidlc update --check更新は候補を完全に検証してから有効なポインタを切り替えます。更新が失敗した場合は、直前の一貫したインストール状態へ自動で戻ります。
特定の版へ切り替える
特定のバージョンを使いたいときは
aidlc use <x.y.z> を実行します。保持されていない版なら導入したうえで、プロジェクトファイルを変えずにマシンで有効な版を切り替えます。1
aidlc use 2.8.1プロジェクトの版を固定する
プロジェクトで使う版を固定するには
aidlc config --pin <x.y.z> を使います。必要なら該当版を導入・検証したうえで .aidlc-version を書き出し、プロジェクトのピンを登録します。マシンで有効なポインタは変えません。固定を解除するには aidlc config --unpin を使います。1
2
aidlc config --pin 2.8.1
git add .aidlc-versionコミットするのは
.aidlc-version のみです。アンインストールする
アンインストールには
aidlc uninstall を使います。既定では、インストーラーが管理するコマンドと保持している全バージョンを取り除きますが、プロジェクトのツリーは変更しません。マシンの設定、更新キャッシュ、ピン登録、既定のハーネスは残ります。--purge を付けると、これらのマシン記録も併せて取り除きます。1
2
aidlc uninstall
aidlc uninstall --purge --yesアンインストールは確認を求め、root 所有・パッケージマネージャー所有・所有権が混在したコマンドは拒否します。
8. 応用
ここでは、通常の導入から一歩進んだ使い方を見ていきましょう。
オフライン導入
ネットワークに繋がらないマシンへ導入する場合は、接続済みのマシンで完全なリリース資産を1つ取得し、そのディレクトリをそのまま持ち込みます。リリース資産のセットがそのままオフラインパッケージになります。
接続済みのマシンで取得します。
1
gh release download v2.8.1 --repo awslabs/aidlc-workflows --dir ./aidlc-offline切り離されたマシンで、取得したディレクトリを指定して導入します。
1
2
bash ./aidlc-offline/install.sh \
--from ./aidlc-offline --offline1
2
& .\aidlc-offline\install.ps1 `
-From .\aidlc-offline -Offline--from はローカルのリリースセットを読み、オフラインモードを含意します。--offline はネットワークアクセスを禁じ、--from の指定を必要とします。バンドルが欠けている、または checksums.txt を認証できない場合、ローカルインストールは処理を止めます。バージョン固定とCIでの利用
CI や新規クローンでは、コミットした
.aidlc-version の版を先に導入してから設定します。版を取得して導入し、その版でピンと設定を行う流れです。1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
version=$(cat .aidlc-version)
tag="v$version"
tmp="$(mktemp -d)"
gh release download "$tag" --repo awslabs/aidlc-workflows --dir "$tmp" \
--pattern install.sh --pattern aidlc-release.intoto.jsonl
gh attestation verify "$tmp/install.sh" \
--bundle "$tmp/aidlc-release.intoto.jsonl" \
--repo awslabs/aidlc-workflows \
--signer-workflow awslabs/aidlc-workflows/.github/workflows/release.yml \
--source-ref "refs/tags/$tag"
sh "$tmp/install.sh" --version "$version" --quiet --yes
rm -rf "$tmp"
aidlc config --pin "$version" --project-dir "$PWD" --quiet
aidlc config --project-dir "$PWD" --harness kiro --mcp none --quiet
aidlc doctor --project-dir "$PWD" --quietこれで、チームや CI が同じ版を、署名検証を含めて再現できます。
gh attestation verify はブートストラップスクリプト自体を実行前に認証する手順で、一次資料の CI 手順に沿っています。ミラー・プロキシ・CA バンドル
企業内のネットワークで導入する場合は、リリースの取得先やCA証明書を差し替えられます。ミラーは
--release-base-url <url>（環境変数 AIDLC_RELEASE_BASE_URL）、カスタムCAバンドルは --ca-bundle <絶対パス>（環境変数 AIDLC_CA_BUNDLE）で指定します。ミラーのベースURLは HTTPS を使い、認証情報・クエリ・フラグメントを含められません。プロキシはブートストラップスクリプトが curl・wget・Invoke-WebRequest に委譲します。ここは必要な場合のみ設定する項目で、通常の導入では触れる必要はありません。9. まとめ
この記事では、AI-DLC 2.8.1 の新しい導入手順を見てきました。
- 第1段階 — インストールスクリプト（
install.sh/install.ps1）でaidlcコマンドと全ハーネスランタイムを導入する - 第2段階 — プロジェクトのルートで
aidlc config --harness <name>を実行し、aidlc doctorで確認して、ハーネスから/aidlc <説明>で始める
従来との違いは、ビルド済み配布物（
dist/<harness>/）を取得して cp で手コピーしていた bun 前提の方式が、aidlc コマンドの導入とその aidlc による設定という2段階に整理された点です。導入されるのはランタイムを内包した自己完結型の aidlc バイナリで、フックもこのバイナリ経由で動くため bun / Node.js が不要になりました。更新・バージョン固定・アンインストールも aidlc update・aidlc config --pin・aidlc uninstall で扱えます。手動でファイルを管理したい場合は、aidlc-runtime-X.Y.Z.tar.gz を使う道も残っています。まずは、自分の環境でインストールスクリプトを実行し、
aidlc doctor が通るところまで確かめてみましょう。Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 26AI-DLC Workflow V2のインストール: cpコピーからインストールスクリプトへ This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article