Kiro Crewとは何ですか？AmazonのKiroとどういう関係がありますか？

Kiro CrewはAmazon傘下のKiroチーム（kiro.dev）によるオープンソースプロジェクトで、「永続的な開発ワークスペース」に位置づけられています：AIプログラミングタスクをセッションを超えて継続・自己改善させます。2025年にAWSがリリースしたagentic IDE「Kiro」と同名・同チームですが、Kiro Crewは独立したオープンソースのワークスペースランタイムであり、kiro-cliを通じてモデルを呼び出し、VS Codeを中心にターミナル、ファイルシステム、ブラウザの3つの統合を組織します。

Kiro Crewはどのようにセッション間の記憶を実現していますか？

ソースコードレベルでは5種類のストレージが役割分担しています：MemoryStoreは事実（7/28日の2段階アクセス減衰付き）を保存し、VectorMemoryStoreは意味検索を行い、LessonStoreは実行可能な経験（トリガー条件と適用境界を含む）を保存し、session_ledgerはセッション台帳を記録し、Workspace/steeringアーカイブはプロジェクトレベルの取り決めを保存します。これに3つのアラームが付随します：CronServiceによる定時タスク、ハートビートによるキープアライブ、AutoNudgeServiceによるアイドル時の自動リマインドです。これらにより、タスクがセッション終了とともに失われないことを保証します。

Kiro Crewは使う価値がありますか？どのような境界がありますか？

「常駐型AI同僚」という形態を検証したいチームが手軽に試してみるのに適しています：単一ファイルのcurlスクリプトとしてインストールし、KIRO_API_KEYを設定するだけで動作し、教訓の蓄積メカニズム（出典の注釈と境界条件付き）は控えめに設計されています。境界も同様に明確です：Amazonのkiro-cliとサブスクリプションに強く依存しており、それをインストールしない自作ソリューションは、5種類のストレージと起動ループの最小限の骨組み（約100行でコア概念を検証可能）です。2026年9月時点でプロジェクトにPyPI/npmの配布チャネルはなく、スターの規模は実際の使用規模とイコールではありません。

Kiro Crew：AIプログラミングをワンタイム会話から常駐する同僚へ

技術分解：AI技術フレームワークを解説——説明、分析、技術評価、価値判断、導入。作者：永亮

title: “技術分解008｜Kiro Crew：AIプログラミングをワンタイム会話から常駐する同僚へ” cover: cover.png author: 永亮 digest: ""

技術分解：AI技術フレームワークを解説——説明、分析、技術評価、価値判断、導入。作者：永亮

大多数 AI プログラミング会話には共通の終点があります：チャットウィンドウを閉じると、会話内で蓄積された判断、修正、コンテキストがすべてゼロに戻り、次回は一からやり直しになります。2026年7月、Amazon傘下のKiroチームは、この問題に対する的を射た答えをオープンソースコミュニティに投げ入れました：Kiro Crew——あなた自身のハードウェア上で動く永続的な開発ワークスペースです。セッションを超えて作業を記憶し、修正を教訓として固定化し、繰り返されるパターンをスキルとして固定化し、人が不在のときでもスケジュール通りに作業を継続します。プロジェクトの作成から2ヶ月、2026年9月時点で約3,891のスター、213人の貢献者を獲得し、v0.6.0がリリースされています。この記事では6つのことを分解します：それは何か、核心メカニズムからソースコードレベルまで、技術的にどう評価するか、使う価値があるか、どう導入するか、そして——もし同様の永続ワークスペースを自作したい場合、最小限の骨組みは何か、です。

一、これは何か

一言で言えば：Kiro Crewはローカルまたはあなた自身のサーバー上で動くオープンソースの開発ワークスペースであり、その核心的な主張は、作業がチャットウィンドウを閉じることで終わってはならないということです——セッション、記憶、スケジュール、タスクチェックポイントがすべて永続化され、修正と失敗は長期的な教訓となり、繰り返されるパターンは再利用可能なスキルとして固定化されます（README原文：persistent, self-learning, and self-evolving）。

重要な事実を先に整理しておきましょう。リポジトリはkirodotdev/KiroCrew、2026年7月16日作成、主言語はPython（バックエンド約1,492ソースファイル）、フロントエンドはReact + TypeScript + TailwindのダッシュボードとElectronデスクトップシェル（約3,712ソースファイル）、さらに2,502のテストファイルがあります。コードライセンスはApache-2.0ですが、リポジトリのNOTICEファイルには明確に書かれています：著作権はAmazon.com, Inc.またはその関連会社に帰属します；KiroとKiro Crewの名称とロゴは商標であり、ソフトウェアライセンスの範囲には含まれません。AWSのKiroと同じチームによる作品です——デフォルトのエージェントランタイムはKiroのコマンドラインツールkiro-cliであり、Kiro CrewがACPプロトコルを通じてこれを駆動します。READMEの謝辞リストには複数のAmazon従業員のアカウントが直接見えます。貢献者をコミット数で見ると、上位4名で合計3,000回以上のコミットを行っており、3人のメンテナーBolin Chen、Joe Guo、Zezhen Xuがその中に含まれています——これは本物のチームが集中的に投入しているプロジェクトであり、操作で盛り上げた熱量ではありません。

二、核心メカニズム

2.1 3層の分割：ランタイム、パーソナリティ、ゲートウェイ

Kiro Crewのアーキテクチャドキュメントはシステムを3層に分割しており、この切り分けがすべてを理解する鍵です。

一番下にあるのはkiro-cli、エージェントランタイムです（エージェントではないことに注意）：LLM接続、ツール実行（bash、ファイル読み書き、grep）、MCPサーバー管理、セッション永続化、コンテキスト圧縮を持ち、外部にACP——Agent Client Protocolを公開します。これはstdio上で動作するJSON-RPC 2.0インターフェースであり、任意のオーケストレーターが駆動できます。中間層はエージェント設定です：~/.kiro/agents/以下のJSONファイルで、「このエージェントがどう振る舞うか」のみを記述します——システムプロンプト、有効にするツール、接続するMCPサーバーなどで、各エージェントはkiro-cli acp --agent <名前>の形式で実行されます。一番上がKiro Crewそのものです：asyncioプロセスであり、デスクトップアプリ、Webダッシュボード、コマンドライン、Slack、Discord、Telegram、Feishu、WeChat、iMessageなど十数もの操作面を同一のランタイムに多重化し、ランタイムが意図的に表明しないすべてを補完します：スケジュール、承認、記憶、セキュリティポリシー、メッセージ接続です。

1つのメッセージの完全な旅はこうです：まずゲートウェイのフック（自動返信、変換、注入、拒否）を通り、あるセッションにルーティングされ、ContextBuilderがコンテキスト（記憶、スキル、教訓、履歴）を組み立て、ACPのプロンプトとしてkiro-cliに送られます。モデルはテキストとツール呼び出しをストリームで返し、ゲートウェイはイベントストリームを操作面に押し戻すと同時に、JSONL形式のセッションログに追記し、非同期で記憶の固定化を1回トリガーします。強調すべき詳細が1つあります：ツール呼び出しはゲートウェイからランタイムに直通しません——すべてのツール呼び出しは、まずKiro Crew自身のPreToolUseチェックポイントを通過する必要があり、kiro-cliが実際の実行を許可されます。セキュリティ境界はオーケストレーション層に引かれており、プロンプトの自覚に頼るものではありません。

2.2 永続化：5種類のストレージがそれぞれの役割を担う

Kiro Crewにおける「永続化」はスローガンではなく、構造が明確な5種類のストレージです。

1つ目は人が読むMarkdown記憶です。memory.pyのMemoryStoreは3つのファイルを管理します：preferences.md（ユーザー設定）、projects.md（進行中のプロジェクトコンテキスト）、history/ディレクトリ以下の日付ごとの要約（YYYY-MM-DD.md）。SQLite FTS5全文検索インデックスを合わせてキーワード検索を行います。履歴には明確な減衰勾配があります：直近14日分の内容は完全に注入され、15〜60日分はタイトルと最初の1件と残りの件数のみを注入し、61〜180日分は1行の日付とセッション数に圧縮され、180日を超えるものは読み込まれません。ハートビートサービスは365日を超えるファイルをディスクから削除します。記憶は多ければ良いというものではなく、この勾配がエンジニアリング上のトレードオフの宣言です。

2つ目はベクトル記憶です。vector_memory.pyのVectorMemoryStoreは同様にSQLiteに格納され、意味キー値、コンテキスト記録、教訓の3種類の行に分かれ、埋め込みベクトルはBLOB形式でデータベースに保存されます。検索はハイブリッドスコアリングです——ソースコードの_hybrid_scoreはキーワードスコアとベクトルコサインスコアを合成し、ベクトルがない場合は自動的に純粋なキーワードにフォールバックします。コンテキスト記録はタグ設定ごとに独自の減衰率を持ち、重要度がソートに関与します。埋め込み計算はプロセス内で完了し、バンドルされたllama-cpp-pythonを使用するため、独立した埋め込みサービスは不要です。その代償として、モデルを変更するとベクトル空間全体が無効になるため、ソースコードにはreconcile_embedding_spaceが実装されています：モデル変更後、古い埋め込みはすべて無効化され再計算され、2種類のベクトル空間が混在してソートされるのを防ぎます。

3つ目は教訓です。learn.pyのLessonStoreは追記のみ（append-only）のJSONLファイルであり、各教訓が1レコードで、増加のみで変更はありません。ユーザーが「いや、今後は完了前にフロントエンドチェックを先に走らせてくれ」と言うと、この文はワークスペースレベルのスコープで保存され、今後のセッションでプロンプト注入時に検索されます。教訓も意味キー記憶としてベクトル化され、書き込みパスには完全な重複排除と置換ルールがあります：新しい値が古い値の置換を確認すると、古い値を参照するコンテキスト記憶は廃止されます——ソースコードのコメントには1つの測定記録が残されています：数時間有効にしたストレージで、101件のコンテキスト記憶のうち21件が廃止され、そのうち14件はこのルールによるものです。同じコメントは、なぜ毎回の固定化で最大3件しか廃止しないのかも説明しています：置換された値は、在庫の一部を切り取るのではなく、それを言い換える少数の記録を廃止すべきだからです。

4つ目はセッション台帳であり、これは「セッション間の継続」における最も厳格な設計です。session_ledger.pyは各セッションごとに作業台帳を維持し、状態フィールドにはgoal（目標）、phase（段階）、next_step（次のステップ）、tried_approachとtried_rejected_because（試したこと、なぜ却下されたか）、artifacts（成果物）が含まれます。台帳を書くrecord()には厳格な規律があり、ソースコード原文：a phase must never move without a logged, classified reason——段階の進行は、記録され分類されたイベントを伴わなければならず、空回りやステップのスキップはデータ構造自体によって拒否されます。各実行サイクルにおいて、台帳は小さな[work ledger]ブロックとしてレンダリングされ、プロンプトに注記され、エージェントは各ラウンドで自分が以前すべきと認定したことを確認できます。台帳は専用のロックファイルで保護されたディレクトリに書き込まれ、ロックするのはパスではなくiノードです——ディレクトリを削除した後、キューに待機しているライターが削除されたロックを取得し、ゴーストファイルに書き込むのを防ぐためです。agent_state.pyはサイドカーJSONとプロセス間アドバイザリ・ファイルロックを使用し、ダッシュボードプロセスとCLIプロセスが同一状態に対する読み書きの競合を解決します。

5つ目はマルチメンバー分離型記憶ストアです。memory_stores.pyは名前付き記憶ストアメカニズムを実装しています：各メンバーは独自の記憶ストアを持つことができ、所有権リストを合わせて他のメンバーまたは再構築されたプロセスが古いデータを乗っ取るのを防ぎます。廃止には専用のマークがあり、V1古いストアとV2新しいストアの世代区分はロジックに組み込まれています。ソースコードのコメントはこのメカニズムを非常に直球に説明しています：もし同じ述語がそれを作ったコードからこっそり逸脱する可能性があるなら、その述語はない方がマシだ——静かな失敗は述語がないことよりも悪い。この種のコメントはリポジトリ内で密度が非常に高く、設計決定とその理由がコードの横に残されています。

2.3 スケジューリングと実行ループ：3つの「アラーム」がそれぞれの種類の無人監視を管理

無人監視は「バックグラウンドでループを回す」という一言ではなく、ソースコードには3つのメカニズムがあります。

1つ目は定時タスクです。cron.pyのCronServiceはタスクをcrons.jsonに保存し、every、at、cronの3つの表現をサポートし、タイムゾーンはIANA名をZoneInfoで解析します——「平日の朝9時」といった要件は作成者のタイムゾーンで保存されます。各起動には予算分解のセットがあります：起動トリガー、請求時審査、セッションプールキューイング、全体のウェイクアップの4つの段階それぞれに制限時間枠が割り当てられ、総額のデッドラインで全体の実行を兜とし、予算超過は失敗となり、連続して失敗したタスクは無限にリトライするのではなく自動的に一時停止します。

2つ目はハートビートです。heartbeat.pyのHeartbeatServiceはHEARTBEAT.mdタスクリストを維持し、周期的に起動して1つずつ実行します。エージェントの応答にHEARTBEAT_KEEPセンチネルが含まれている場合、そのタスクは未完了と判断され、次のサイクルに持ち越されます——「まだ終わっていない、次回また来る」は、モデルが自覚的に状態を復唱するのではなく、機械可読な信号にされています。リストの読み書きはすべてプロセス間ロックを通過し、ハートビートサービスの最終的な「読み取り→置換」トランザクションは、別のプロセスが刚刚追加したタスクを上書きしません。

3つ目は自動ナッジ（催促）です。autonudge.pyのAutoNudgeServiceはセッションにバインドされたナッジループを管理します：1つのセッションに目標ループを挂けることができ、アイドルタイマーが時間になるとそれを押して次のステップに進ませます。ループは実時計予算を持ち、予算超過で自動停止し、停止理由はすべてディスクに保存され、ゲートウェイ再起動後ループはディスク状態から復元します。これに付随するのが構造化モニターです——エージェントが「このデプロイを見張って、終わったら教えて」と言うと、システムはこの文をプローブ状態を持つ監視ループとして解析し、エージェントが自分で戻って見ることを覚えているのに頼りません。

セッション側のサポートもソースコードにあります：アクティブなセッションの背後には、専用のkiro-cli ACPプロセスか、共有多重化ランタイム上のセッションハンドルのどちらかがあります——セッションは論理的分離境界であり、必ずしも1つのOSプロセスとは限らず、アイドルセッションは再利用されるのを待ってウォームプールに入ります。

2.4 自己改善：修正からスキルへの3段階の蓄積

「自己改善」は3段階に分割されており、各段階には独自のストレージとトリガー条件があります。

第1段階は教訓です：修正は即座に保存され（LessonStore）、ベクトル記憶の教訓領域に書き込まれるとき意味重複排除を経ます——同じルールの重複投稿は積み上がりません。第2段階は固定化です：非同期で動作するLLM固定化ツールがセッションログを設定、プロジェクトコンテキスト、日次サマリーに圧縮します。トリガー条件はメッセージ数（設定とプロジェクトは約30メッセージ）とアイドル時間（日次履歴は約3時間アイドル）です。第3段階はスキルです：繰り返し現れる作業パターンは自動的にSKILL.mdファイルとして固定化されます。YAMLヘッダーには来歴記録（自動生成、どのセッションから来たか、作成と洗練時間、再利用回数）が含まれ、来歴の証明クラスはAutoSkillProvenanceです。スキルは生成すれば終わりではありません——バイトレベルで重複するスキルは重複排除され、定時タスクから参照されたスキルは淘汰から免除され、すべてのスキルはダッシュボードで表示、編集、削除可能です。

すべてを合わせてみましょう：このメカニズムは現在約1,492のPythonソースファイルによって支えられており、テストファイルは2,502個でソースコードより多いです——2ヶ月のプロジェクトに対して、この比率自体がチームが信頼性をどこに置いているかを示しています。

三、技術評価

結論の根拠の形から言いましょう：このプロジェクトにはベンチマークも、引用できるパフォーマンス数値もありません。評価はエンジニアリング完成度とガバナンスの品質で見るしかありません。そしてこの2つは恰好、最も硬い部分です。

エンジニアリング完成度を見るには、2つの指標があります。1つはソースコードコメントの意思決定密度です：session_ledger.pyのiノードをロックする理由、vector_memory.pyの「廃止上限は3」の測定根拠、agent_state.pyの「読み取り不可は意見がないことを意味しない」という読み書き規律——ほぼすべての自明でない関数に「なぜこうするか」の説明が付いており、これは長期のメンテナーが残す痕跡です。2つはテスト比率です：2,502のテストファイル対1,492のソースファイル、設定にはベースラインファイル、エラーコードベースラインファイルがあり、セキュリティルールにはsemgrepスキャンディレクトリがあります。ガバナンスの品質を見ると：リポジトリには順序付けられた10の設計原則（TENETS、1条はSafety first、競合時は前方が勝ちトレードオフは書き留める）、明記されたRFCプロセス、商標とコードライセンスの分離宣言があります——このガバナンステキストは2ヶ月のプロジェクトではスペック超過の構成です。

同類のソリューションと比べると、この方向のヘッドソリューションは大きく3つに分類されます：ターミナルペアプログラミングツール、汎用エージェントオーケストレーションフレームワーク、クラウドホスト型エージェントサービスです。Kiro Crewはこれらのどの枠にも入りません：それは「ランタイム」をkiro-cliにアウトソースし、自分はオーケストレーションと状態しか管理しません。状態の5点セット（セッションとログ、記憶、承認、ガバナンス上限、イベントバス）はプラットフォームが最終的な発言権を持ち、残りのすべてのインターフェースは置換可能なアプリになります——その第10条原則の原文はeverything is an app（すべてはアプリである）であり、アプリ化がうまくいっていない表面はプラットフォームの欠陥であり、表面をコアに押し込むライセンスではありません。代償も同様に明確です：システム全体はkiro-cliに強く依存し、agent.providerはacpに固定され、Kiroエコシステムに入らないとこれは動きません。

人気データには冷水を浴びせる必要があります。スター約3,891、貢献者213人、どちらも低い数ではありませんが、未解決のイシューとPRの合計は1,548であり、スター数に対して非常に高い比率です——試用者は多く、磨きは未完了です。配布チャンネルも特殊です：PyPIとnpmは通らず、デスクトップパッケージとインストールスクリプトはプロジェクト独自のCDNを通り、コンテナイメージはGHCRにあり、ダウンロード数は公開統計から不明です。貢献者リストにはAmazon従業員のアカウントが目立つ位置を占め、外部コミュニティの貢献割合はまだ小さいです。実際の使用規模は限られており、この判断は明確にしておく必要があります。

四、価値判断

本当の問題は本当です：エージェントは仕事をし終わると忘れ、修正は繰り返し発生し、スケジュールと承認はチャットウィンドウに散らばっています——これは2026年にAIプログラミングを真剣に使うすべてのチームが経験しているロスです。Kiro Crewの答えは、ワークスペース状態をインフラとして扱うことです：5種類のストレージ、3つのアラーム、3段階の蓄積、すべてが自分で制御するハードウェア上にあり、記憶はローカルファースト、デフォルトで送信しません。「同僚」という位置づけに対して、それは非常に完全なエンジニアリング上の説明を与えています。

境界も同様に明確です。第1に、エコシステムへの縛り：kiro-cliとKiroアカウントシステムに強く依存しており、AWS Kiroを使わない人は最初の段階で躊躇させられます。これは汎用オープンソースプロジェクトにとって最も重い足枷です。第2に、アーキテクチャの上限：ゲートウェイはセッション、ランタイム、状態が同一マシンのシングルプロセスモデルであり、水平スケーリングとマルチマシン展開は現在図にありません。第3に、プラットフォームの違い：Windowsには同等のOSレベルのサンドボックスがなく、ソースコードの選択は失敗時に閉じるです——終了を宣言しない限り、非サンドボックス実行を解放しません。第4に、商標はAmazonの手にあり、コードはフォークできますが、名前は持っていけません。いつ使うべきか：すでにKiroエコシステムにいて、セッションを超えて常駐する開発ワークスペースを望み、データを自分のマシンに残す必要があるチーム——それが既製の答えです。いつ使うべきでないか：kiro-cliを使わないチーム、マルチマシンオーケストレーションが必要なシナリオ、または単に軽量なチャットシェルが欲しいだけの場合——最初の2つはアーキテクチャ上満たさず、最後の1つは重すぎて不必要です。

五、導入方法

インストールは1行、インストール後http://localhost:5476を開くとダッシュボードです：

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

前提条件は1つだけ：ゲートウェイがあるマシンにkiro-cliをインストールし、個別にログインします。初回起動時に自動チェックされ、ガイダンスが表示されます。インストーラはデフォルトで独自管理のCPython 3.12（uvブートストラップ）を使用し、システムインタープリタには触れません。常駐させたい場合はkirocrew service installとし、Linuxはsystemdサービス、macOSはlaunchdをインストールします。コンテナパスも既製です：

docker run -d --name kirocrew -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew ghcr.io/kirodotdev/kirocrew:stable

日常の使い方は5つのコマンドでほとんどのシナリオをカバーします：kirocrew chatで対話、kirocrew run TASK.mdでチェックポイント付きタスク実行、kirocrew cronで定時タスク管理、kirocrew spawn run “タスク”で並列サブエージェント起動、kirocrew securityで監査。運用側では3つを覚えておきます：kirocrew doctorでヘルスチェック、kirocrew logsでログ確認、ダッシュボードのSettingsで毎日1回の匿名使用ハートビートをオフにできます。選定アドバイスは2つ：データディレクトリはKIROCREW_HOMEで明示的に指定しバックアップに含める——記憶、教訓、スキルがすべてそこにある；ダッシュボードを外部に公開する場合は必ずトークン認証付きのリモート設定を通し、デフォルトのループバックバインドはセキュリティベースラインでありデフォルト値ではありません。

六、同様のソリューションを自作する方法

「自分で1セット書く」はこのテーマでは特に実現可能です。なぜならKiro Crew自体がランタイムと状態レイヤーを分離できることを証明しているからです。最小限の骨組みは7ステップです：

まずレイヤーを切る：既存のエージェントランタイム（kiro-cli、claude-codeのACPアダプタ、またはstdio JSON-RPCで駆動できる任意のランタイム）を選び、自分はゲートウェイだけを書く——メッセージルーティング、セッションテーブル、状態ストレージ。この切り分けにより、難易度は半減します。
セッション台帳：各セッションに追記のみ（append-only）のJSONLトランスクリプトと、goal、phase、next_step、tried_approachを記録する状態ファイルを1つ用意します。書き込みは一時ファイルとリネームによるアトミック書き込みを使用し、マルチリーダー・マルチライターシナリオではプロセス間アドバイザリロックを追加します。「段階の進行には理由が必要」を書き込み検証にし、これが無人監視で逸脱しないための重要な規律です。
デュアルインデックス記憶：Markdownファイルは人が読み、SQLite FTS5がキーワードを管理し、ベクトルはBLOBで同庫に保存して意味検索を行い、ハイブリッドスコアリング、ベクトルなし時はキーワードにフォールバックします。埋め込みはプロセス内のllama-cppクラスのソリューションで十分で、モデル変更時は古いベクトルを全量無効化します。
固定化ツール：非同期ループを1つ起動し、メッセージ数またはアイドル時間でトリガーし、モデルにトランスクリプトを設定、プロジェクト、日次サマリーの3段階に圧縮させます。サマリーは減衰ウィンドウを持ちます（14日全文 / 60日要約 / 180日1行）。
教訓ライブラリ：追記のみのJSONLで十分で、プロンプト注入前にスコープでフィルタリングし、書き込み時に意味重複排除と置換された値の古いレコードの廃止を行います。
3つのアラーム：Cron式スケジューリングはタイムゾーンと各段階の時間制限予算を持ち、ハートビートファイルはセンチネル信号で「まだ終わっていない」を表現し、目標ループは実時計予算とディスクに保存された停止理由を持ちます。
セキュリティゲート：すべてのツール呼び出しは自分のチェックポイントを通過してから解放し、拒否ディレクトリ、センシティブパス保護、認証情報のマスキングと組み合わせます。このステップは省略できません——無人監視が拡大するのは権限であり、知能ではありません。

7つのステップを合わせると、2人のチームで1四半期で使用可能なバージョンを納品できます。Kiro Crewの2000以上のテストファイルはもう半分の真実を思い出させます：回る骨組みに価値はなく、ロック、境界、失敗モードを一寸一寸磨き上げてこそ価値が出るのです。

結論

Kiro CrewはAIプログラミングワークスペースを「一回の会話」から「一つの永続的な状態」へと再定義しました：5種類のストレージ、3つのアラーム、3段階の蓄積、すべてローカルファーストであり、各層はソースコードレベルのエンジニアリング説明を与えています。それはAmazon Kiroチームのオープンソース作品であり、kiro-cliに強く縛られ、実際の使用規模はまだ検証待ちです——しかし、すでにKiroエコシステムにいて、エージェントにセッションを超えて作業を記憶させたいチームにとって、これは現在完成度が最も高い既製の答えです。自作したい人にとって、そのソースコードはどのブログよりも誠実な教材です。

参考ソース

Kiro Crew GitHubリポジトリ（README、TENETS、GOVERNANCE、NOTICE、MAINTAINERS）：https://github.com/kirodotdev/KiroCrew
Kiro Crewアーキテクチャドキュメント（docs/architecture/overview.md：3層分割、メッセージフロー、記憶ライフサイクル、バックエンドコンポーネント図）：https://github.com/kirodotdev/KiroCrew/blob/main/docs/architecture/overview.md
Kiro Crewソースコード：src/kiro_crew/agent.py（エージェント仕様とガバナンス投影）、session.py（セッションプールとライフサイクル）、memory.py（MemoryStore、markdown + FTS5）、vector_memory.py（VectorMemoryStore、ハイブリッド検索とベクトル空間調整）、memory_stores.py（名前付き記憶ストアと所有権）、learn.py（LessonStore、append-only JSONL）、session_ledger.py（作業台帳とrecord規律）、agent_state.py（サイドカー状態とプロセス間ロック）、cron.py（CronServiceスケジューリングと予算分解）、heartbeat.py（HeartbeatServiceとHEARTBEAT_KEEPセンチネル）、autonudge.py（AutoNudgeService目標ループ）、skills.py（スキル読み込み、来歴証明と重複排除）、session_summary.py（要約とマスキング）
GitHubリポジトリメタデータと貢献者リスト（api.github.com、2026年9月時点）；最新リリースv0.6.0（2026-09-11）
kiro.dev（Kiroとkiro-cli公式サイト）