はじめに

前回の記事で、自律エージェント管理レイヤーの Kiro Crew を、AWS のプライベート EC2 に立てました。ただ、立てた直後の Kiro Crew は、会話できるだけの汎用アシスタントです。特定の仕事を任せるには、もう一手間かけて「仕込む」必要があります。

Kiro Crew では、特定の役割を与えたエージェントをクルーメイトとしてメンバー追加できます。今回は、その一例として、Qiita 記事作成を手伝ってもらうアシスタント qiita-writer を作ってみます。役割を prompt に書いて専門メンバーを作り、GitHub・draw.io・Qiita preview と配線して、下書きの作成からブランチへの push、PR の作成までを手伝ってもらえる状態にしていきます。

まずは結論から

専門メンバーは agent spec（JSON）と prompt 本文（Markdown）の2点で作る
GitHub 連携は MCP ではなく git コマンド直叩き、公開は人が手で行う
EC2 の Qiita preview は SSM ポートフォワードで手元ブラウザに通す

想定される読者

Kiro Crew を立てたので、活用の場を広げてみたい方
定型業務に特化した専門メンバーを自前で作って運用したい方
リモートサーバ上で動くツールの画面を、手元から確認する配線を知りたい方

専門メンバー（クルーメイト）の作成

Kiro Crew における「メンバー」とは、特定の役割を与えられた1体のエージェントのことです。ここでは、Qiita 記事の執筆だけを担当する qiita-writer を例に、メンバーがどんな部品でできているか、どこに何を置くか、そして実際にハマった落とし穴まで順に見ていきます。

agent spec とメンバーの関係

メンバーは、ダッシュボードのクルーメイト一覧に並びます。下の画面では、これから作る専門メンバー qiita-writer が、最初からいる汎用の default と並んでいます。default は「すべての新しいチャットで使う」汎用アシスタント、qiita-writer はそれとは別に足した専門メンバー、という関係です。

メンバーは、大きく3つの部品でできています。まず全体像を置き場所とあわせて示します。

部品	役割	置き場所（例）
agent spec（JSON）	メンバーの定義。gateway が読む登録ファイル	`~/.kiro/agents/<member>.json`
prompt 本文（Markdown）	役割・固有ルールの規範	`~/.kiro/crew/workspace/agent-prompts/<member>-prompt.md`
専用メモリ	そのメンバーだけの記憶（会話や学習の蓄積）	`~/.kiro/crew/memory_stores/member-<member>-<id>`

それぞれを補足します。

agent spec … エージェントの定義そのものです。名前、使うモデル、prompt 本文の参照先などを書いた JSON ファイルです。Kiro Crew の gateway（本体プロセス）は、この spec を読んでメンバーを認識します。
prompt 本文 … そのメンバーに与える「役割と固有ルール」を書いた Markdown ファイルです。「文体はです・ます調」「公開操作は絶対にしない」といった、毎回必ず守らせたい規範をここに書きます。
専用メモリ … そのメンバーだけの記憶です。会話や学習の蓄積がここに貯まり、ほかのメンバーとは混ざりません。default を選択することで、汎用アシスタントと記憶を共有することもできます。

spec が「定義」、prompt が「規範」、メモリが「記憶」。この3点が揃って初めて、ただの汎用チャットが「書き方のルールを知っている専門メンバー」になります。

ダッシュボードでメンバーの詳細を開くと、この「束ねられた部品」が1枚で見えます。中央のメンバーから、ベース・ワークスペース・メモリストア・モデルが枝分かれしているのが、いま説明した構成そのものです。

実物の spec はそれほど大げさなものではありません。名前・使うモデル・prompt 本文の参照先・使わせるツールを並べた JSON です。核だけ抜き出すと、こんな形をしています。

{
  "name": "<member>",
  "model": "auto",
  "prompt": "file:///home/<user>/.kiro/crew/workspace/agent-prompts/<member>-prompt.md",
  "tools": ["fs_read", "fs_write", "execute_bash", "@drawio", "@aws-mcp"],
  "allowedTools": ["@drawio", "@aws-mcp"],
  "mcpServers": {
    "drawio": { "command": "npx", "args": ["-y", "@drawio/mcp"] },
    "aws-mcp": { "command": "...", "args": ["..."] }
  }
}

prompt が本体の Markdown を file:// で指しているところ、mcpServers に MCP の起動定義があるところが要点です。

prompt は、公式には本文を JSON に直接書く（"prompt": "あなたは…"）方法と、外部ファイルを file:// で参照する方法の両方がサポートされています。短い役割なら直書きでも構いませんが、qiita-writer の prompt は固有ルールが長いので、Markdown ファイルに切り出して file:// で参照しています（編集しやすく、差分も追いやすいため）。

spec と prompt 本文の置き場所

spec と prompt 本文は、置く場所を間違えると動かなくなります。まず正しい置き方を示します。

spec（JSON） は ~/.kiro/agents/ 配下に置く。
prompt 本文（Markdown） は ~/.kiro/agents/ の外に置く。具体的には crew 配下の作業領域（~/.kiro/crew/workspace/agent-prompts/）。
spec の JSON から、その prompt 本文を file:// のパスで参照してつなぐ。

{
  "name": "<member>",
  "prompt": "file:///home/<user>/.kiro/crew/workspace/agent-prompts/<member>-prompt.md"
}

一点だけ注意があります。prompt 本文は「agents 配下の外ならどこでもいい」わけではありません。crew の直下（~/.kiro/crew/ のすぐ下）や、memory / lessons で始まる名前の場所は「managed（システム管理）領域」として弾かれます。安全なのは、上の例のように crew 配下の workspace のそのまた配下です。

prompt 本文を ~/.kiro/agents/ の配下に置くと、全セッションの初期化が止まり、メモリ系の機能が軒並み動かなくなります。 gateway は ~/.kiro/agents/ 配下のファイルを拡張子を問わず全部 agent spec（JSON）として読もうとするため、prompt の Markdown を置くと「読めないスペックがある」状態になり、その影響がそのメンバーだけでなく全セッションのポリシー解決にまで及ぶからです。

置き場所のルールが分かったところで、実際にどうやって置くかです。ここで一つ制約があります。ツールやエージェント自身からは ~/.kiro/agents/ 配下にファイルを書けません（ガバナンス層のポリシーで保護されているため）。つまりメンバー自身に「自分の spec を作って」と頼んでも作れません。spec の JSON や prompt 本文を新しく置くときは、ターミナルから直接保存するか、ダッシュボードの GUI 経由で行います。

GUI から編集する画面はこんな様子です。モデル・プロンプトの参照先・使わせるツールを、フォームで設定できます。今回は prompt が長いので Markdown ファイルに切り出して file:// で参照していますが、最近は改善が進みこのプロンプト欄自体が広く扱いやすくなっているので、本文をここに直接べた書きする手も十分ありです。

ルールを縛る3つの層

メンバーに「ルール」を守らせる仕組みは、実は1種類ではありません。性質の違う3つの層を使い分けます。ここは、ルールをどこに書くか迷ったときの判断軸になります。

層	効き方	向いているもの
prompt（固定ルール）	毎セッション必ず読み込む恒常の規範	「文体はです・ます調」「公開操作はしない」など、常に守るべき方針
Hooks / git フック（機械的ゲート）	特定の条件で必ず作動する強制装置	「秘密情報を含むファイルの push を弾く」など、自分で仕掛ける例外なしの一線
lessons（学習補正）	失敗や指摘から学んで蓄積される	「このコマンドには `--region` を必ず付ける」など、使う中で判明した個別の補正

3つのうち prompt と Hooks は、多くの開発ツールにある「設定ファイル」と「フック」に近いものです。Kiro Crew らしいのは lessons です。たとえば qiita-writer には「preview 用の SSM コマンドには --region ap-northeast-1 を必ず付ける（省くと手元のリージョン設定に引きずられて失敗する）」という補正が入っています。これは最初から分かっていたことではなく、一度失敗し、その指摘を受けて初めて貯まったものです。prompt が「最初に書く規範」なら、lessons は「使いながら後から足されていく補正」で、メンバーは使うほど賢くなっていきます。

この3層のうち、最初に手を動かすのは prompt だけで十分です。Hooks は本当に必要になったときに最小限を足し、lessons は運用の中で勝手に育っていきます。軽いものから足していくのが、専門メンバーを無理なく育てるコツです。

その下に、外せない「床（floor）」がある

ここまでの3層は、どれもこちらが決めて設定するルールです。prompt も書くのは自分、Hooks も仕掛けるのは自分、lessons も自分の運用で貯まる。では「設定し忘れたら素通りするのか」というと、そうではありません。3層のさらに下に、Kiro Crew 本体が持つ最後の砦があります。これが floor ルールです。なお、ダッシュボードの設定画面では「多層防御アーキテクチャ」「ガバナンスポリシー」と表記されています。

分かりやすい例が、main などの保護ブランチへの直接 push です。試しに qiita-writer に git push origin main を叩かせようとしても、実行される前に本体が機械的に拒否します。prompt に「main には push しない」と書いたから止まるのではありません。何も書いていなくても、本体の仕様として最初から止まっているのです。

floor ルールには、ふつうの設定可能なルールと決定的に違う性質があります。

設定層より先に評価される。 ユーザーが書いた prompt や Hooks の判定よりも前に、floor が先に効きます。つまり「設定を緩めたから抜けた」が起きません。
無効化できない（opt-out を参照しない）。 設定で切るスイッチがそもそも用意されていません。「デフォルトで有効」なのではなく、常に有効で外せないのがポイントです。
押し切れない形で止める。 保護ブランチへの push だけでなく、push 先が $(...) のようなシェル展開に紛れて宛先を事前に確定できないケースも、別の floor が「宛先を確認できない push」として弾きます。「どこへ送るか曖昧な push」は通さない、という設計です。

実際、設定画面で GIT PUBLISH のカテゴリを開くと、main への直 push を止めているのは1本のルールではなく、抜け道をふさぐ8本の集合だと分かります。引数なしの git push・HEAD のような実行時解決の宛先・force-push の refspec・ワイルドカードの一括 push・--mirror / --all まで、保護ブランチに届きうる経路を一通り押さえています。しかもこのカテゴリには鍵アイコンが付いていて、「すべての組み込み拒否を無効化」をオフにしても解除されません。

floor ルールは「人間が直接コマンドラインを叩くこと」そのものを封じる完全なセキュリティ境界ではなく、エージェントが素直にコマンドを叩く経路に対する強い摩擦として設計されています。スクリプトで何重にも包めば理屈のうえでは迂回の余地はありますが、少なくともエージェントがうっかり main を吹き飛ばすような事故は、本体が最初から構造的に止めてくれます。

ここが Kiro Crew を安心して活用できる理由の核心だと感じています。prompt の書き方をどれだけ工夫しても、「書き忘れ」や「指示の揺れ」でルールが抜けるリスクは残ります。しかし保護ブランチへの直 push のような絶対に越えてはいけない一線は、設定の善し悪しに依存せず本体が止めてくれる。だからこそ、取り返しのつく範囲（記事ブランチへの push・PR）はエージェントに大きく任せられます。設定で守る3層と、設定に関係なく守られる floor。この二段構えが、専門メンバーを安全に走らせる土台になっています。

外部との配線

ここまでで、ルールを知っている専門メンバーができました。ただし、できたのは「頭」だけです。prompt で文体や見出しを教え込んでも、いまの qiita-writer は自分の頭の中で考えて答えを返すだけで、書いたものを保存する手も、図を描く手も、AWS を調べる手も持っていません。記事を書く相棒にするには、成果物を保存する先（GitHub）、図を作る道具（draw.io）、AWS を扱う手（AWS MCP）につないで、はじめて実践で使えるエージェントになります。この章では、その「手」= 3本の配線を作ります。

外部との配線となると MCP を連想しがちですが、今回はそれぞれの相手に合わせて異なる経路を選びました。次のとおりです。

配線	経路
GitHub（push / PR）	素の `git` コマンド
draw.io（図のソース）	MCP（メンバー spec に配線）
AWS（ドキュメント / API）	MCP（メンバー spec に配線）

GitHub だけ MCP を使わず素の git にしています。なぜその経路を選んだのかは、各配線の節でそれぞれ説明します。

Qiita CLI の準備

各配線の説明に入る前に、今回利用している Qiita CLI（@qiita/qiita-cli）について触れておきます。これは記事をローカルの Markdown で管理し、コマンドで Qiita に反映できる公式ツールです。

導入はごく定型です。記事を管理するディレクトリ（この構成では EC2 上の記事リポジトリ）で、次の流れを一度通します。

# 1. 記事リポジトリで Qiita CLI をインストール（Node.js は公式要件のバージョン以上が必要）
npm install @qiita/qiita-cli --save-dev

# 2. 設定ファイル・.gitignore・GitHub Actions 雛形を生成
npx qiita init

# 3. バージョンが出ればインストール成功
npx qiita version

次に Qiita のアクセストークンを発行して CLI に登録します。トークンは https://qiita.com/settings/tokens/new から、read_qiita と write_qiita の権限を付けて発行します。

# 4. 発行したトークンを登録（Qiita アカウントと紐付く）
npx qiita login
# 発行したトークンを入力: <トークンを貼り付けて Enter>
# Hi <ユーザー名>! と出ればログイン成功

ここまでで npx qiita preview / npx qiita pull / npx qiita publish が使えるようになります。

今回はさらに一歩進めて、main への push をトリガーに GitHub Actions が npx qiita publish を自動実行する、「push だけで公開」 の構成を取っています。記事ブランチを PR で main にマージした瞬間に Qiita へ反映されるので、手元で publish コマンドを打つ必要がありません。

GitHub 連携

記事は Qiita 用のリポジトリで管理しています。これを Kiro Crew の origin に接続すると、エージェントが自分で記事をコミットし、PR まで出せるようになります。

接続に必要なのは GitHub の PAT（Personal Access Token、個人アクセストークン） です。PAT は GitHub が発行する「パスワード代わりの鍵」で、これを Kiro Crew に渡すことで、エージェントが自分の代わりにリポジトリを読み書きできます。

PAT はパスワードと同じ重みの秘密情報です。.env ファイルや Kiro Crew の vault（秘密情報の保管庫）に入れて渡し、絶対にリポジトリにコミットしないでください。

記事を Git 管理するなら、public/.remote/ の扱いも決めておきます。npx qiita pull を実行すると、Qiita 側の記事情報が差分確認用に public/.remote/ へ落ちてきます。差分を見るには便利ですが、Git 管理に入れると pull のたびに更新ノイズが増えるので、.gitignore で除外するのが扱いやすいです。あわせて .env と、ローカル固有の設定（この構成では .kiro/settings/）も除外対象にしておきます。

なお、当初は GitHub の MCP を配線し、ファイルを push する専用ツール（push_files）を使っていました。ただ、この方式には実務上つらい点がありました。MCP のツールはファイルの中身を丸ごと引数に載せて送る作りで、数十 KB になる記事を push するたびに全文を転送するため、とにかく時間が掛かりました。それなら、エージェントのシェルから普通に git add / git commit / git push を叩くほうが、速くて確実でした。認証も、PAT を ~/.git-credentials に1本だけ置いておけば git がそのまま使ってくれるので、ツールごとに資格情報を渡し直す必要がありません。そこで GitHub の MCP は spec から外し、GitHub 操作は git 直叩きに一本化しました。

実際にエージェントがやっているのは、ごく普通の git 操作です。記事ブランチに追加コミットするときの一連はこうなります。

# 送る前に必ずリモートの最新を取り込んで、ズレていないか確認する
git fetch origin
git status

# 記事ファイルだけをステージ（関係ないファイルを巻き込まない）
git add public/<記事スラッグ>.md

git commit -m "記事を加筆"

# 宛先ブランチ名はリテラルで固定（変数展開や $(...) は使わない）
git push origin article/<記事スラッグ>

認証は ~/.git-credentials の PAT が自動で効くので、コマンドにトークンを埋め込みません。main への直 push は、前述の floor ルールで本体が機械的に止めています。

push の中身を自由にやらせるわけではありません。qiita-writer には次の運用ルールを prompt で課しています。

記事の修正は、同じブランチに追加コミットする。新しい PR は作らない。
PR の作成で止める。 マージはしない。
Qiita への公開（publish）は絶対にしない。

このルールの背景には、「不可逆に近い操作はエージェントにやらせない」という線引きがあります。ブランチへの push やコミットは、間違えてもブランチを捨てればやり直せます。しかしマージや公開は、一度やると取り消しが難しい。だから、取り返しのつく作業までをエージェントに任せ、取り返しのつかない操作は人間が最後のボタンを押す、という分担にしています。

draw.io 連携

記事には図がつきものです。今回は、図のソースファイル（.drawio）を記事と同じリポジトリで版管理します。図を記事と同じライフサイクルで扱えるので、「記事は更新したけど図は古いまま」といったズレが起きにくくなります。

ただ、今回は Kiro Crew on EC2 という構成の都合上、draw.io との連携も少し複雑になりそうだったので、図の作り方は、軽いものから段階的に進めることにしました。

まずアスキー図で初稿を作る。 構成・流れ・関係を、文章とアスキー図（文字で描いた簡易な図）で起こします。この段階で「登場する要素は何か」「どうつながるか」を確認します。図の正しさはここで詰め、見た目はまだ気にしません。
シーケンス図やフローチャートは mermaid で足りる。 Qiita は mermaid（テキストで図を描く記法）をそのまま表示できるので、処理の流れや認証のやり取りのような図は、mermaid のコードブロックを記事に直接書けば済みます。この用途に draw.io は不要です。
draw.io を使うのは、アスキー図や mermaid では力不足なものだけ。 具体的には、AWS のサービスアイコンが並ぶ構成図のような、見た目の作り込みが要るブロック図です。ここで初めて draw.io に進みます。

draw.io で AWS 構成図を作るときは、アイコンの指定に一手間あります。

AWS アイコンの「スタイル文字列」（draw.io が図形を描くための指定）は、記憶で書かず、draw.io の MCP ツール（search_shapes）で最新のものを取得します。AWS アイコンは世代更新で変わるため、取得して使うことで自動的に最新へ追従できます。
生成した .drawio ファイルは、記事と同じブランチの diagrams/<記事スラッグ>.drawio に push します。これで図もリポジトリで版管理されます。

最終的な図の調整とレビューは、ブラウザで行います。

app.diagrams.net を GitHub モードで開き、リポジトリ内の diagrams/<記事スラッグ>.drawio を開くと、ブラウザ上で図を編集できます。
ブラウザでの変更は GitHub にも自動でプッシュして最新を保ちます。
記事本文に貼る画像（PNG / SVG）は、draw.io からローカルに書き出します。

AWS MCP 連携

もう一本、AWS を扱うための配線も足しました。AWS MCP Server です。MCP を配線すると qiita-writer が AWS を直接扱えるようになります。できることは2種類あります。

AWS 公式ドキュメントの検索。AWS 記事を書くときに、記憶ではなく一次情報を引きに行けます（認証不要）。
AWS API の実行。実際に AWS を操作・取得するところまでできます（こちらは認証が必要です）。

この配線で、専門メンバーの作りについて一つ大事なことが分かりました。MCP ツールを「どこに足すか」で、どのメンバーに効くかが変わるという点です。

デフォルト（本体）に足すのか、メンバーに足すのか

Kiro Crew のダッシュボードには MCP を追加する GUI があります。ところが、ここで追加しても、それだけでは qiita-writer のセッションにツールが生えませんでした。

画面上は「オンライン・8ツール」と緑のステータスで表示されているのに、いざ qiita-writer のチャットで AWS ドキュメントを引かせようとすると「そんなツールはない」と言われます。

確認したところ、GUI での追加先は、既定で kirocrew 本体（全体のデフォルト設定）になっていました。つまり、ここに設定しても別メンバーである qiita-writer のセッションには配線されず、そのメンバーの spec に個別に書く必要がありました。

各メンバーに同じ MCP を書き直すのが面倒な場合、共有の口も公式で用意されています。spec の includeMcpJson を true にすると、mcp.json（グローバル / ワークスペース）に定義した MCP サーバーを、各メンバーの mcpServers とは別に取り込めます。

今回は qiita-writer に持たせたかったので、本体ではなくメンバーの spec に定義しました。具体的には、MCP サーバーの定義（mcpServers）・許可するツール（tools）・許可リスト（allowedTools）の3か所を揃えて書く必要があります。どれか一つでも欠けると、「許可はされているのに起動定義がない」「起動はするのに許可されていない」といった中途半端な状態になり、ツールが生えません。

{
  "name": "<member>",

  "tools": ["@aws-mcp", "@drawio"],

  "allowedTools": ["@aws-mcp", "@drawio"],

  "mcpServers": {
    "aws-mcp": { "command": "...", "args": ["..."] },
    "drawio":  { "command": "npx", "args": ["-y", "@drawio/mcp"] }
  }
}

この MCP が使う AWS 権限はどれか

今回の配線は AWS API の実行まで含みます。つまり qiita-writer は、この MCP を通じて実際に AWS を操作できます。そうなると当然、「このツールはどの権限で AWS を叩くのか」が問題になります。ここが、専門メンバーを作るうえで見落としやすい落とし穴でした。

結論から言うと、MCP が使う AWS 権限は、どのメンバーに足したかとは無関係に、EC2 のインスタンスプロファイルに割り当てられた1つのロールに集約されます。

理由は AWS SDK の資格情報の決まり方にあります。AWS SDK（boto3）は、資格情報を次の順で探します。

環境変数 → ~/.aws のプロファイル → （最後に）EC2 インスタンスプロファイル

このプライベート EC2 には、環境変数にもプロファイルにも AWS の資格情報を置いていません。すると SDK はチェーンの最後まで落ちて、EC2 自身に割り当てられたインスタンスプロファイルのロールを使います。つまり、MCP を qiita-writer に足そうが、別のメンバーに足そうが、最終的に AWS を叩く権限は全部この同じ1つのロールになります。メンバーごとに別々の権限にはなりません。

この「権限が1ロールに集約される」挙動は、Kiro Crew を EC2 に立てたからこそ出てくる事象です。手元の端末で Kiro Crew を動かしていれば、資格情報は ~/.aws のプロファイルや環境変数から来ることになります。資格情報を置いていない EC2 だからこそ、SDK がチェーンの最後まで落ちてインスタンスプロファイルのロールを拾うことになります。

成果物の確認

ここまでで、頭（prompt）に手（GitHub・draw.io・AWS）が付き、qiita-writer は記事を書いてブランチに push できるようになりました。残るは「書いたものを公開前に自分の目で確かめる」工程です。これが、EC2 構成では地味に一手間かかります。

記事を書いたら、公開前に見た目を確認したくなります。Qiita CLI には npx qiita preview というローカルプレビュー機能があり、手元のブラウザで記事の仕上がりを確認できます。ところが、Kiro Crew をプライベート EC2 に立てている構成では、ここに一つ壁があります。

EC2 の preview

npx qiita preview は、EC2 の中で 127.0.0.1:8888（EC2 自身からしか見えないアドレス）にプレビュー用のサーバーを立ち上げます。しかし今回立ち上げた EC2 は、プライベートサブネットにいて Public IP も持たない構成です。つまり、手元の端末からその 8888 番ポートへは直接たどり着けません。

これは第1回で Kiro Crew のダッシュボードに到達するために使った SSM ポートフォワードと、まったく同じ考え方で解けます。SSM（AWS Systems Manager）のポートフォワードは、EC2 のポートを手元のポートへ安全にトンネルする仕組みです。ダッシュボードのときと同じ要領で、今度はプレビュー用の 8888 番を手元に通します。

tmux 常駐と SSM ポートフォワード

手順は2段です。まず EC2 側でプレビューを起動し、次に手元の端末からトンネルを張ります。

EC2 側では、プレビューを tmux で常駐させて起動します。tmux はターミナルのセッションを切り離しても中のプロセスを生かし続けるツールです。これを使うと、SSH 接続が切れてもプレビューが動き続けます。

tmux new -s preview
npx qiita preview
# Ctrl+B → D でセッションを切り離す（プロセスは生き続ける）

次に、手元の端末から SSM ポートフォワードでトンネルを張ります（事前に session-manager-plugin のインストールが必要です）。

aws ssm start-session \
  --target <INSTANCE_ID> \
  --region ap-northeast-1 \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["8888"],"localPortNumber":["8889"]}'

--region オプションは必ず EC2 を立ち上げているリージョンで付けてください。省くと、端末の AWS CLI 既定リージョンに引きずられ、インスタンスが見つからずトンネルの確立に失敗します。

トンネルが張れたら、手元のブラウザで http://localhost:8889 を開きます。EC2 の中で動いているプレビューが、そのまま手元のブラウザに表示されます。

ここまでで、「書く → 保存する → 見た目を確かめる」という執筆の一周が、すべてプライベート EC2 の上で閉じました。Qiita 記事作成アシスタントも立ち上がり、ますます記事作成が捗りそうです。

まとめ

今回は、Qiita 記事作成をお手伝いしてくれるアシスタントエージェントを Kiro Crew on EC2 に立ち上げてみました。EC2 特有の制約も若干ありましたが、快適に執筆を進められる環境を手にすることができました。

クルーメイトと呼ばれる Kiro Crew のメンバーを追加する手順も分かりましたので、目的に応じたメンバーを増やして自分だけの Kiro Crew 環境を育てていきたいと思います。

プライベート EC2 で Kiro Crew を立ち上げる手順はこちらから。

参考リンク