アマゾン ウェブ サービス ジャパン合同会社（以下、AWS ジャパン）は、2026 年 9 月 24 日（木）に、AWS ジャパン オフィスで「Kiro Meetup #8」を開催しました。Kiro Meetup は、Kiro を使っている方が集まり、使い方の工夫や最新アップデートを共有するコミュニティイベントです。今回はオフィス移転後の新しい会場での開催となりました。 当日は、AWS から Kiro の最新アップデートと Kiro Crew の詳細を紹介したあと、三菱電機株式会社の中村 信夫 氏と小森 裕之 氏、東海旅客鉄道株式会社の倉澤 瑞希 氏、株式会社オープンアップシステムの藤牧 正和 氏にライトニングトークでご登壇いただきました。同じ日の午後には、同会場でハンズオン「手を動かして実感する、Kiro が変える開発体験」も開催しています（ ハンズオンの開催報告 もあわせてご覧ください）。本記事では、Meetup の模様をレポートします。 イベント概要 開催日時: 2026 年 9 月 24 日（木）18:00〜20:30 会場: AWS ジャパン オフィス アジェンダ Kiro の最新アップデート: AWS ジャパン Developer Transformation エンゲージメントマネージャー Katz Ueno (カツ) Kiro Crew Dive Deep: AWS ジャパン ソリューションアーキテクト 小西 杏典 お客様ライトニングトーク 三菱電機株式会社 中村 信夫 氏、小森 裕之 氏 東海旅客鉄道株式会社 倉澤 瑞希 氏 株式会社オープンアップシステム 藤牧 正和 氏 クロージング ネットワーキング 本イベントの司会進行は AWS ジャパン 事業開発マネージャー 井形 健太郎が務めました。 開会のご挨拶 冒頭では、シルバーウィーク明けの平日夜に集まった参加者へのお礼とともに、Kiro Meetup の成り立ちを紹介しました。Kiro Meetup は 2025 年に Amazon Q Developer の Meetup として始まり、Amazon Q Developer や Kiro を使っている方がユースケースやアップデートを共有し、和気あいあいと過ごす場として続けてきました。オフィス移転の影響で間が空いたものの、今後も継続して開催していく予定です。 Kiro の最新アップデート スピーカー: AWS ジャパン Developer Transformation エンゲージメントマネージャー Katz Ueno (カツ) 最初のセッションでは、Katz が前回の Kiro Meetup（2026 年 3 月）以降の半年間を振り返り、86 件の Changelog から注目の 8 件を紹介しました。大きな流れは、Kiro Web の一般提供や Kiro Crew のオープンソース公開で使える場所が増えたこと、そして Cloud Sessions などで実行場所がローカルからクラウドへ広がったことです。 Kiro IDE 1.0 / 1.1 : エージェントとのやり取りに集中できる画面「Agent Focus」が加わりました。権限はワークスペースごとにも全体共通でも設定でき、カスタムエージェントは Markdown で定義できます。Windows と Linux の ARM64 環境でもネイティブに動作するようになりました。 Kiro Web の一般提供開始（9 月 1 日） : ブラウザだけで開発できるようになりました。対話しながら進める Collaborative モードと、計画から PR の作成までを自律的に進める Autonomous モードがあります。 Kiro CLI 2.0 と V3 : Windows 11 でネイティブに動作するようになり、CI/CD に組み込めるヘッドレスモードも加わりました。IDE や Web と同じハーネスで動く V3 も、プレビューとして公開されています。 Cloud Sessions と Configuration Sync : セッションをクラウド上で動かせるようになり、別のマシンから続きを再開できます。 .kiro の設定も、クラウドを通じて複数のマシンで同期できます。 モデル : OpenAI の GPT-5.6 と、Anthropic の Claude Opus 5、Claude Sonnet 5 が使えるようになりました。9 月 16 日には、Kiro Enterprise 向けに Claude Fable 5.1 のプレビュー提供が始まっています。 ガバナンスとコンプライアンス : Kiro が ISO/IEC 27001:2022 の認証範囲に加わり、IDE と CLI は HIPAA 適格になりました。利用状況のメトリクスを OpenTelemetry で送信できるほか、超過利用に上限を設定することもできます。 仕様駆動開発の強化 : タスクを並列で実行できるようになりました。途中の承認を挟まずに要件・設計・タスクをまとめて作る Quick Spec（公開時の名称は Quick Plan）と、要件のあいまいな点や矛盾を洗い出す Analyze Requirements も加わっています。 Kiro Crew の登場 : 複数の Kiro CLI をまとめて動かす、常駐型のエージェント基盤です。詳しくは次のセッションで紹介されました。 最後に、登壇で使った資料は Kiro Crew で下書きしたことを種明かし。アップデートの一覧とリンクなど、Kiro Crew が Changelog を読み込んで作成したことを紹介しました。あわせて、開発者向けコミュニティ AWS Builder Center をご紹介。相互のコミュニケーションが取れることもアピールしました。 Kiro Crew Dive Deep スピーカー: AWS ジャパン ソリューションアーキテクト 小西 杏典 続いて、ISV/SaaS 業界のお客様を支援するソリューションアーキテクトで、Kiro CLI のコントリビューターでもある小西が、Kiro Crew の仕組みを解説しました。 小西はまず、いまの AI エージェント開発には、人が席を離れると作業が止まる、セッションをまたぐと前の会話を忘れる、セッションが直列にしか動かない、という 3 つの課題があると指摘しました。Kiro Crew は、これらを解決する「永続的なオープンソースのワークスペース」で、次の 4 つの特徴を備えています。 永続的かつ自己改善型 : メモリとスケジュールがセッションや再起動をまたいで残り、ユーザーからの修正は「レッスン」として蓄積されます。 マルチエージェントオーケストレーション : cron や Webhook をきっかけに複数ステップのタスクを自律的に実行し、サブエージェントを並列に動かします。 オープンで拡張可能 : App SDK で独自のアプリを組み込め、Slack や Teams などのメッセージチャネルからも操作できます。 セキュアで、あなたの管理下に : OS のサンドボックス、段階的な承認ゲート、自社のハードウェア上での実行、監査ログを備えています。 編集・実行・デバッグを繰り返す「インナーループ」は Kiro CLI や Kiro IDE で対応できますが、スケジュール実行や CI の監視のように人が離れても動き続ける「アウターループ」には常時稼働のゲートウェイが必要です。Kiro Crew はこのゲートウェイとしてセッション、メモリ、セキュリティなどを管理し、その裏で Kiro CLI がエージェントとして動きます。セキュリティは多層防御で、 ~/.aws や ~/.ssh へのアクセスはどの設定でも解除できない基本制限としてブロックしています。 まとめとして小西は、1 つのセッションで開発を進めるなら Kiro IDE / CLI、セッションをまたぐ記憶やスケジュール実行、継続的な運用には Kiro Crew、という使い分けを示しました。 お客様ライトニングトーク ここからは、Kiro を活用している 3 社にライトニングトークでご登壇いただきました。 三菱電機株式会社 中村 信夫 氏、小森 裕之 氏「Kiro が組織に広がってきた！」 三菱電機株式会社 中村 信夫 氏と、小森 裕之 氏にご登壇いただきました。 前半の中村氏は、「重厚長大」の風土が残る電力部門で Kiro をどう広げたかを紹介しました。中村氏の部門では、社員と協力会社が参加する約 700 名のコミュニティ「YOKOHAMA UNITED」を運営しており、毎週の勉強会はこれまでに 137 回を数えます。2025 年 7 月の Kiro 発表の直後から使い始め、AWS を講師に招いた勉強会には約 100 名が参加しました。2026 年 1 月には、約 30 名が 3 日間参加する AI-DLC Unicorn Gym を、トップダウンで開催しました。定員 16 名で募集した社内ハンズオンに 90 名を超える社員が集まったほか、新入社員向けのアジャイル研修では、例年のマシュマロチャレンジの代わりに Kiro を使い、各チームが 2 回のスプリントで飲み会の日程調整システムを作り上げたといいます。中村氏は「組織トップダウンとコミュニティボトムアップのシナジー」が大切だったと振り返りました。 後半の小森氏は、Kiro を開発ワークフローに組み込み、部門のソフトウェア開発フローを標準化する取り組みを紹介しました。部門内の Kiro のユーザーは約 900 名にのぼります。AWS がオープンソースで公開している開発手法 AI-DLC V2 のワークフローを Kiro の上で動かし、2 つの工夫を加えています。1 つ目は、実装とレビューを別のモデルに担わせることです。生成 AI は自分の出力を正しいと思い込みやすいため、Kiro で OpenAI と Anthropic の両方のモデルを選べる点を生かし、Claude のモデルで要件・設計・実装を行い、AI-DLC V2 の工程ごとの AI レビューは GPT-5.6 に任せ、最後に人が確認して承認します。2 つ目は、AI-DLC V2 のレビューの重さを工程ごとに選べるようにしたことです。既定では敵対的検証によるレビューが 2 回走りますが、「重い」という声があったため、工程に応じて回数を減らすなど、品質と時間のバランスを取る設定を試しています。 東海旅客鉄道株式会社 倉澤 瑞希 氏「現場の『こうしたい』を、動くものへ ～Kiro で変わった技術開発の進め方～」 東海旅客鉄道株式会社 倉澤 瑞希 氏にご登壇いただきました。 倉澤氏は新幹線の保線の現場を長く経験したあと、技術開発部の DX チームへ異動し、アプリ開発の経験がないところから取り組みを始めました。Kiro は 2025 年 12 月から利用しており、用途は、データ分析やシミュレーター、3D 点群の可視化などの実装 PoC、要件定義やレビュー、報告資料や研修資料などのドキュメント作成、CI/CD や GitLab などの環境構築・運用の 4 つに広がっています。 代表的なプロダクトとして、駅の改良工事で資材の置き場所が旅客の流れを妨げないかを検証する「駅旅客流動シミュレーション」と、ベテラン社員の暗黙知を AI がインタビュー形式で引き出して蓄積する「熟練者ナレッジ蓄積」についてプロトタイプを短期間で実装した例を紹介しました。 倉澤氏がプロダクト以上に大きかったと話したのは、技術開発の進め方の変化です。以前は研究員が要望と業務知識を整理してベンダーやメーカーに伝え、設計・実装してもらっていました。Kiro の導入後は、研究員が自然言語で「こうしたい」を言語化し、Kiro がスペック化と実装を担い、研究員が確認して判断する、というサイクルを自ら高速に回せるようになりました。倉澤氏は「Kiro は魔法ではなく増幅器」と表現し、0 を 100 にするのではなく、研究員が持つドメイン知識や現場の課題という「1」を大きくしてくれるものだと説明しました。そのうえで、Kiro を導入するだけでなく、使い方そのものをチームで育てることが大切だと締めくくりました。 株式会社オープンアップシステム 藤牧 正和 氏「人的資本経営による AI 導入と直面した課題のご紹介」 株式会社オープンアップシステム 藤牧 正和 氏には、AI 駆動開発を進める中で直面した失敗や課題を中心にご紹介いただきました。 同社は社員 700 名弱のシステム開発会社で、2025 年 1 月から AI の研究を始め、同年 3 月には Amazon Q Developer を使い始めました。約 1 年半の試行錯誤を経て、AI を中心にシステム開発ができる段階にたどり着き、現在は大手 SIer からの AI 開発導入の相談にも応じています。全部門で AI を使っており、最もよく使われているのは Kiro です。 直面した課題として、藤牧氏は次のような点を挙げました。「自分の仕事が増えるだけ」という抵抗は、新人が 1 か月かけてもできるかどうかだった作業が 1 時間ほどで終わったことをきっかけに解消し、一気に広まりました。セキュリティはガイドラインとオプトアウト設定で対応し、プロンプトの上手い下手による差は Steering で AI の動かし方を標準化して埋めました。プロンプトの工夫に時間をかけすぎるバイブコーディングの限界にぶつかったことから、仕様駆動開発で正確に開発できる Kiro に全員で移行しています。現在の課題は、AI に指示する力を持つ人材と、上流から開発全体を見通してコーディネートできる人材の育成で、採用と育成の方針も見直したといいます。 最後に藤牧氏は、AI を導入しても仕事は減らず、むしろできることが増えて仕事も増えると述べ、人を資本として活かす「人的資本経営」の観点で AI への投資を進めていると語りました。 おわりに 今回の Meetup では、Kiro の半年分のアップデートと Kiro Crew の仕組みを紹介し、3 社に Kiro を組織に広げる取り組みを語っていただきました。三菱電機株式会社様は、トップダウンとコミュニティによるボトムアップの両輪で利用を広げています。東海旅客鉄道株式会社様は、研究員が自ら「こうしたい」を実装まで回せるようになりました。株式会社オープンアップシステム様は、全部門での AI 活用で直面した課題と人材育成の見直しを共有してくださいました。3 社に共通していたのは、Kiro を導入するだけで終わらせず、使い方そのものを組織で育てている点です。 AWS ジャパンは、今後も Kiro Meetup を継続して開催し、Kiro を使う皆様が知見を共有できる場を提供してまいります。ご登壇いただいた皆様、ご参加いただいた皆様、ありがとうございました。 登壇資料 Kiro の最新アップデート: Kiro Meetup #8 Kiro アップデート (2026/3/21〜2026/9/24) Kiro Crew Dive Deep: Kiro Crew Dive Deep 三菱電機株式会社 中村 信夫 氏、小森 裕之 氏「 Kiro が組織に広がってきた！ 」 東海旅客鉄道株式会社 倉澤 瑞希 氏「 現場の『こうしたい』を、動くものへ ～Kiro で変わった技術開発の進め方～ 」 株式会社オープンアップシステム 藤牧 正和 氏「 人的資本経営による AI 導入と直面した課題のご紹介 」

本ブログは、株式会社エナリス 星野 友宏 氏、KDDI アジャイル開発センター株式会社 御田 稔 氏、同 山本 直弥 氏、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 安藤 が共同で執筆しました。 みなさん、こんにちは。AWS ソリューションアーキテクトの安藤です。 脱炭素に関する規制や情報開示のルールは変化が速く、企業が追うべき情報は増え続けています。今回は、 株式会社エナリス （以下、エナリス）と KDDI アジャイル開発センター株式会社 （以下、KAG）が Amazon Bedrock AgentCore と Strands Agents で構築した「ESG 戦略意思決定プラットフォーム」（以下、ESG ダッシュボード）をご紹介します。ESG 関連のニュースや規制動向を AI エージェントが日次で収集し、エナリスの事業視点で読み解いた記事と、取るべき対応アクションを提示する仕組みで、2026 年 7 月から社内で利用されています。本記事では、担当者の判断を AI の記憶として蓄積し、次回以降の記事に反映する仕組みを中心に、品質とコストを両立させるための設計を紹介します。 背景と課題 エナリスは、需給管理・電力卸・電力小売で培ったノウハウをもとに、PPA や VPP などの脱炭素ソリューションを展開する企業です。その事業は電力に関する制度や脱炭素関連の規制と密接に結びついており、制度の変化は自社サービスの設計や顧客への提案に直結します。一方で、ESG 関連のニュースや規制動向の調査は担当者の手作業に頼っており、情報の網羅性や解釈の深さが個人に左右されていました。 また、ニュースを要約するだけでは、「エナリスとして何をすべきか」を考える工程は人に残ります。そこで、自社への影響と対応アクションまでを AI が提示すること、そして担当者の判断を次回以降の提案に反映できる仕組みにすることを目指しました。 ESG ダッシュボードの概要 ESG ダッシュボードは、次の 3 つの画面で構成されています。 記事一覧 ：日次で自動生成された記事と、URL やキーワードを指定してその場で生成した記事を表示します。各記事には、エナリスの視点で再構築した本文、リスク／機会、対応アドバイス、AI による信頼性評価が表示され、担当者はコメントを登録できます 週次サマリ ：優先度の高い記事を週単位でまとめます。担当者は、提示された対応アクションにエナリスとして取り組むかを、記事ごとに「承認」「保留」「却下」で登録します 意思決定履歴 ：過去の判断と、却下した場合の理由を振り返れます ESG ダッシュボードの記事一覧画面 ESG ダッシュボードの週次サマリ画面 アーキテクチャ システム全体構成図 ESG ダッシュボードは、次の 4 つの経路で構成しています。 リアルタイム記事生成 ：AWS Amplify 上のフロントエンドから、Amazon Cognito の ID トークンを使って AgentCore Runtime を直接呼び出します。Runtime は JWT による呼び出し元の認可 に対応しているため、Amazon API Gateway を挟まずに呼び出せます。生成結果は ストリーミング で逐次表示します 画面表示・データ登録 ：記事一覧の取得や、意思決定・コメントの登録は、API Gateway と AWS Lambda による REST API で処理します 日次の記事生成 ：Amazon EventBridge が毎日起動する Lambda が、Amazon S3 の収集対象 URL リストを読み込み、URL ごとに Runtime を起動します 週次サマリの生成 ：Lambda が Amazon DynamoDB の記事をもとに Amazon Bedrock のモデルを直接呼び出し、サマリを生成します。決まった形式で集約するだけの処理なので、ここではエージェントを使っていません Runtime は起動元に合わせてリアルタイム用と日次用の 2 つがあり、どちらも生成した記事を DynamoDB に直接書き込みます。担当者の意思決定とコメントは、Lambda が DynamoDB と AgentCore Memory の両方に書き込みます。DynamoDB は画面に表示するための記録、AgentCore Memory はエージェントが参照するための記憶、と役割を分けています。 AgentCore Runtime 内部のエージェント構成 Runtime の中は Strands Agents の Agents as Tools パターンで構成しており、オーケストレーターがサブエージェントをツールとして持ち、①→②→③→④ の順に呼び出します。 ① 情報源判定（ Claude Haiku 4.5 ） ：収集対象のサイトを選定します。①の中で呼び出す robots.txt 確認のエージェント（ Claude Sonnet 4.6 ）が、AI エージェント向けの外部 Web 検索 API で利用規約と robots.txt を確認し、取得してよいかを判定します。この検索結果は判定専用とし、生成や評価には使いません ② 記事取得・意味分解（Claude Haiku 4.5） ：ニュース記事（リアルタイムでは最新 2 件、日次では対象日付の記事）を取得し、関連情報を 2 つの経路で集めます。エナリスが自社サイトで公開している「 エナリスジャーナル 」の関連記事は AgentCore Browser 上の独自ツールで都度取得し、制度動向に関する社内の解釈をまとめた資料は Amazon Bedrock Knowledge Bases からセマンティック検索で引き出します。取得は②で完了させ、③④はその結果を引き継ぎます ③ 記事再構築・リスク／機会判定（Claude Sonnet 4.6） ：②の情報と、AgentCore Memory から取り出した過去の判断をもとにニュースを再構築し、リスクと機会、実務・経営への示唆を整理します ④ 対応アドバイス・信頼性評価（Claude Haiku 4.5） ：③の記事を前提に対応策を提言し、その内容を自動評価します。完了後、オーケストレーターが結果を DynamoDB に保存します 技術的ポイント 1：担当者の判断を記憶し、次の記事に反映する 担当者が画面で登録した意思決定とコメントは、Lambda が CreateEvent で AgentCore Memory に書き込みます。書き込んだ内容からは 組み込みの戦略 で長期記憶が抽出され、次回以降の記事生成で参照されます。使っている戦略は次の 2 つです。 User preference 戦略 ：過去のコメントやレビューの観点 Semantic 戦略 ：進行中、または予定している対応策 意思決定は承認・却下のときだけ、コメントは常に登録します。保留を登録しないのは意図的な設計で、迷いのある判断を混ぜず、確定した判断だけを記憶に残すためです。 AgentCore Memory は、ユーザーとエージェントの会話から好みや重要な事実を抽出し、以降の会話に活かす使い方が代表的ですが、ESG ダッシュボードでは会話ではなく、業務画面で登録された担当者の判断を API で直接書き込んで記憶の元にしています。チャットのような対話の形をとらない業務システムでも、利用者の判断を記憶として蓄積し、エージェントの出力に反映できる一例です。 記憶の取り出しには、 RetrieveMemoryRecords を呼ぶ独自のツールを戦略ごとに用意し、それぞれ関連度の高い上位 5 件を取得します。取得した記憶は③記事再構築で参照し、どの観点でニュースを読み解くか、エナリスの取り組みに照らして何をリスクや機会と捉えるかの判断材料にします。④の対応アドバイスは③の記事を前提に作られるため、記憶の内容はアドバイスにも間接的に効きます。モデルを再学習させるのではなく、蓄積した判断を生成のたびに参照する仕組みです。 組織としての知見は、ナレッジベースに持たせています。格納しているのは、電力・燃料関連の制度動向について社内で共有・議論し、その解釈をまとめた資料です。規制の条文などの一次情報はその都度 Web から取得し、ナレッジベースには「その規制変更をエナリスとしてどう捉えるか」を持たせる、という役割分担にしています。 技術的ポイント 2：自動評価と人の確認を組み合わせて品質を担保する エージェントを分割する ：開発の初期には、複数のニュースをまとめて処理すると、本来は別々のニュースの内容が混ざり、1 本の記事にまとまってしまう問題がありました。プロンプトの改善では解消できず、役割ごとのサブエージェントに分けることで解決しています。Agents as Tools では各サブエージェントが独立したコンテキストで処理を行うため、情報の混線を防げたと考えられます。 自動評価と、その限界 ：エナリスと KAG は 前回の記事 でも、人と AI が相互にフィードバックし合って精度を高め合う HCAI（Human-Centered AI）の仕組みを取り入れてきました。ESG ダッシュボードでもこの考え方を引き継ぎ、④が Strands Agents の評価用 SDK である Strands Evals を使って、生成した対応アドバイスをその場で採点します。③の再構築記事、取得した関連情報、ナレッジベースの内容を根拠として渡し、アドバイスが根拠に忠実かといった 9 つの指標で評価して、平均値を A／B／C の 3 段階で画面に表示します。 ただし、この評価の対象は④のアドバイスで、③の記事は根拠の側にあります。③で誤りが混入していても、④がそれに忠実であれば評価は高くなります。多段のパイプラインで最終出力だけを評価しても、途中で生じた誤りは検出できません。そこで③の記事は担当者が画面で確認し、その判断が技術的ポイント 1 の記憶を通じて次回の③に戻る設計にしています。自動評価が④を守り、自動評価の届かない③を人が確認して、その判断を③に返す。守る場所と、判断を活かす場所がそろっていることが、この仕組みの要点です。 評価には当初、オープンソースの評価フレームワークである RAGAS を使っていましたが、別系統で動く外部ライブラリとの連携にオーバーヘッドがありました。Strands Evals への移行で 1 件あたりの評価時間は約 8 分から約 4 分へと約 40% 短縮し、判定結果は移行の前後で一致しています。 技術的ポイント 3：品質を保ったままコストを下げる 構築当初はすべての処理を Claude Sonnet 4.6 で動かしており、LLM の利用コストが課題になりました。Amazon CloudWatch でトークン使用量を可視化し、入力トークンの量とモデルの単価の 2 つの軸で打ち手を重ねた結果、1 回の実行あたりの入力トークンは数千万トークン規模から数十万トークン規模へと 98% 以上減り、1 日あたりの LLM コストは約 88% 下がっています。 入力を削る Web の取得方法を見直す ：HTML をタグごと渡していた処理を改め、①ではページの内容をテキストで返す外部 Web 検索 API に切り替えました（情報源判定 1 件あたり約 800 万 → 約 40 万トークン）。②では AgentCore Browser 上の独自ツールで HTML の除去と構造化を行っています（記事取得 1 件あたり約 100 万 → 約 40 万トークン） 単価を下げる キャッシュを使う ：システムプロンプトやツール定義など毎回同じ部分を プロンプトキャッシュ の対象にしました。情報源判定 3 件での測定では約 400 万トークンがキャッシュからの読み込みになり、その分は通常の入力より低い単価で処理されています モデルを使い分ける ：サブエージェントごとに Claude Haiku 4.5 の出力を検証し、品質に影響が出ない①②④を Haiku 4.5 に移しました。③と、①の中の robots.txt 確認は Sonnet 4.6 のままです。robots.txt 確認は機械的に見えますが、解釈を誤ると取り込んではいけない情報を取り込むことになります。モデルは処理の重要度ではなく、誤りをどこまで許容できるかで選んでいます。 導入効果 2026 年 1 月から AgentCore の導入を進め、約 4 か月の開発を経て、2026 年 7 月からサステナビリティ推進の担当部署で利用が始まりました。 業務面 担当者が手作業で行っていた ESG 関連情報の収集と整理が日次で自動化され、自社への影響と対応アクションの案を起点に検討を始められるようになりました 承認・却下の判断とその理由が意思決定履歴として残り、判断の経緯を後から振り返れるようになりました 技術面 開発の過程で見直しを重ねた結果、構築当初（すべての処理を Claude Sonnet 4.6 で実行し、評価に RAGAS を使っていた時点）と比べて、次の効果が出ています。 入力トークン（1 回の実行あたり）：数千万トークン規模 → 数十万トークン規模（98% 以上削減） LLM コスト（1 日あたり）：約 88% 削減 評価時間（1 件あたり）：約 8 分 → 約 4 分（約 40% 短縮） また、サーバーレス構成のため、ベースとなるインフラの固定費は月額数十ドル程度に抑えられ、OS の保守などの運用負荷もかかりません。 現在は、実際に利用する担当者のフィードバックを受けて改善を続けています。 今後の展望 週次サマリを経営層の意思決定の場でも活用していくほか、同じ構成を、規制への適合性をアドバイスする「規制／ルール分析」機能へ展開する予定です。あわせて、これまでの社内の解釈に加えて、公式の制度ルールや法改正の情報もナレッジベースに順次取り込んでいきます。まずは社内で運用しながら、データの取得方法や、外部に公開できるデータの範囲を整備し、将来的には規制分析の知見を活かした外部向けサービスとしての展開を目指しています。 まとめ エナリスと KAG は、Amazon Bedrock AgentCore と Strands Agents を使い、担当者の判断を AgentCore Memory に蓄積して次回以降の記事に反映する ESG ダッシュボードを構築しました。自動評価の届かない工程を人が確認し、その判断を記憶として同じ段に返す設計は、HCAI を実運用に落とし込む一つの形です。AI エージェントの本番運用に取り組む方の参考になれば幸いです。 著者 星野 友宏 株式会社エナリス 事業企画本部 みらい研究所 技術開発部門 御田 稔 KDDI アジャイル開発センター株式会社 テックエバンジェリスト 山本 直弥 KDDI アジャイル開発センター株式会社 ビジネスイノベーション開発本部 ビジネスイノベーション開発4部 ソフトウェアエンジニア 安藤 麻衣 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 通信・メディア技術本部 通信第二ソリューション部 ソリューションアーキテクト

はじめに # おかげさまで、この10月で豆蔵デベロッパーサイトは立ち上げから5周年を迎えることができました。 5周年を祝う豆香 ローンチのお知らせは2021年の11月29日でした。 /blogs/2021/11/29/site-launch/ その前から少しずつコンテンツを貯めてお知らせを出したので、最初の記事は10月7日の K8s チュートリアルで EKS を構築する記事でした。 /containers/k8s/tutorial/infra/aws-eks-eksctl/ この5年間の歩み # この5年間を振り返ってみます。 初期は、私含め2名でサイトを構築し記事を書いてました。 記事数・執筆者数の推移 # 時期 記事数 執筆者数(累計) 備考 2021-11 15本 2名 ローンチ 2022-03 53本 継続執筆4名/経験7名 初回振り返り 2022-05 100本到達 アクティブ5名 2022-08 200本突破 19名(アクティブ9名) 100→200が加速 2022-12 318本 28名(アクティブ10名超) 平日ほぼ毎日更新 2023-12 522本 34名 開設2年で500本突破 2024-06 590本 56名 2024-12 680本 63名 2025-06 769本 66名 2025-09 809本 71名 800本突破 2025-12 843本 75名 2026-03 876本 76名 2026-09 (直近) 912本 83名 900本突破 ローンチ当初2名だった執筆者は、半年後の2022年5月に5人になり記事数100本到達、6月には月間最多36記事を記録するなど勢いよく立ち上がりました。2022年8月には200本を突破、年末には執筆者28名(アクティブ10名超)に成長しています。 2023年末には記事数522本となり、サイト開設からちょうど2年で500本を突破。検索流入も2023年3月に月間5万クリックに到達するなど、着実に認知度を高めていきました。 その後も成長を続け、2025年9月には記事数800本・執筆者71名を突破。直近2026年9月時点では 記事数912本、執筆者83名 まで広がっています。一人ひとりの興味・関心、専門性を活かした記事が積み重なって、ここまで来られました。 記事数と執筆者数の推移 コンテンツ領域の広がり # ローンチ時は「コンテナ」「マイクロサービス」などわずかなカテゴリーからのスタートでしたが、5年間で以下のようにテーマが大きく広がりました。 2022年 : マイクロサービス、学び、アジャイル開発、IoT、フロントエンド、ロボット 2023年 : モデリング、機械学習 2025年 : 機械学習・生成AI（リニューアル） ロボット・IoT・組込みのようなハードウェア寄りの分野から、アジャイル・品質保証・プロジェクトマネージメントといった開発プロセス系、そして機械学習・生成AIまで、豆蔵の多様な事業領域を反映したラインナップになっています。 長期連載も数多く育ちました。テーマ別に振り返ってみます。 マイクロサービス・バックエンド 逆張りのMicroProfile ～ Helidonで始めるマイクロサービスへの一歩 ～ （ローンチ初期から継続、JJUG CCC 登壇にも発展） Spring Boot による実践マイクロサービス開発 Springの小話 非同期メッセージング (Kafka や AsyncAPI などの非同期メッセージング) アジャイル・プロジェクトマネージメント エクストリームプログラミング解説 アジャイル開発現場におけるTips 業務システムにおけるアジャイル プロジェクト管理 (CCPM理論編・実践編・ツール編、新人プロジェクトマネージャー向け「問題と課題」シリーズ、「デキるPM」改善シリーズ) スクラムマスターのAI活用を考える アジャイルFAQ テスト・品質保証 Jest再入門シリーズ 、 Contract Test 、 Google Test 、 Pytest 品質保証者の憂鬱 フロントエンド Nuxt3入門 Denoを始める 言語・モデリング Javaエンジニアが始めるTypeScript入門 UML をプログラミング言語で実装する （Go・Python・C言語編） SysON で始める SysMLv2モデリング ロボット・IoT ロボットマニピュレータ制御のアルゴリズム robotics/#食品盛り付けロボットシステム「美膳」 AWS IoT基礎編 、 MQTT編 など 学び・育成 オンライン研修の設計勘所 ソフトウェア品質のための統計入門 # (全15回の大作「統計の話をしようじゃないか」) 生成AI トップページのコラム「 豆香の豆知識 」 OpenAI Realtime API シリーズ Kiroでアルバムアプリを作る全6本 AIエージェントとシステムをつなぐMCP入門 EC2でローカルLLMを動かすシリーズ その他 リモートワーク環境紹介 （コロナ禍で定着したテレワーク環境紹介。執筆デビューのネタとしても重宝） 息の長い記事とバズった記事 # サイトの認知度やアクセス数は、公開直後に瞬間的にバズる記事と、公開から何年経っても安定してアクセスを稼ぎ続ける記事の両方に支えられています。その代表例をいくつか挙げてみます。 Rust によるデスクトップアプリケーションフレームワーク Tauri 直感が理性に大反抗！「モンティ・ホール問題」 基本から理解するJWTとJWT認証の仕組み 手書き風ドローツール Excalidraw のススメ 【新人さん向け】A5:SQL Mk-2のおすすめ設定と使い方 文字コード これだけは覚えておこう ～シフトJIS編～ サイト基盤・機能の進化 # 読者・執筆者双方の体験向上のため、地道な改善を積み重ねてきました。目次機能、画像拡大、著者アバール表示、サイト内検索(その後 Algolia に刷新)、タグ検索、数式(KaTeX)対応、おすすめ記事・週間アクセスランキングなど、多くの機能を追加してきました。 サイトを支える静的サイトジェネレーターも、Eleventy から Deno ベースの Lume へ移行するという大きな技術的転換も経験しました。 --> Information 記事執筆中に Deno が1年後に開発を終了するという発表が飛び込んできました。 Deno is joining Cloudflare | Deno Lume を採用しているので、今後の動向を注視して動きたいと思います。 生成AIとの歩み # この5年は、生成AIの進化とともに歩んだ5年でもありました。 2023年、トップページのコラム「豆香の豆知識」を GPT-3 で開始。その後 GPT-4、GPT-4 Turbo、GPT-4o と、豆香は世代交代を重ねてきました（GPT-5 へのアップデートを忘れてたことを記事書いてて思い出しました😅） 2024年には記事サイドバーの挿絵を DALL-E-3 で自動生成する機能を追加。豆香は記事 PR へのコメントやアクセス集計の通知役としても社内で活躍しています 2024年に英訳記事の自動生成を開始(現在は多くの記事が英語で読めます)、2025年には中国語訳も追加し、海外からのアクセスも徐々に伸びています 自社メディアの運営自体に生成AIを積極的に取り込んできたのも、このサイトらしい特徴だと思います。 恒例企画・コミュニティの醸成 # 執筆の裾野を広げるための企画も定着してきました。 アドベントカレンダー : 2022年に初開催(16名、うち7名が初投稿)して以来、毎年末の恒例行事に 夏のリレー連載 : 2023年に初開催(14本、新規執筆者11名、営業職や新卒社員もデビュー) 春の新人向け連載 : 2024年に初開催し、新人エンジニアやプロジェクトマネージャー向けの記事群が生まれる場に これらの企画を通じて、普段は筆を執らないメンバーがデビューするきっかけが生まれ、現在の執筆者数の広がりにつながっています。 SNS をはじめとしたメディアとの連動 # 公式 X(旧Twitter) アカウントの開設から始まり、Bluesky、Facebook、note と発信チャネルを広げてきました。執筆者が JJUG CCC などの社外カンファレンスに登壇する機会も生まれ、記事が社外での発表につながる好循環も生まれています。 豆蔵のニュースページにも注目記事を掲載しています。 技術発信 – 豆蔵 MAMEZO 営業、採用への波及効果 # 記事を書き続けてきたことで、デベロッパーサイトはエンジニア個々人のスキルや得意領域をアピールする場としても機能するようになってきました。実際に、記事を読んだお客様から執筆者を名指しで新規の引き合いをいただき、そのまま受注につながったケースも出てきています。 中途採用の場面でも「デベロッパーサイトの記事を読んでいる」という方が増えており、技術発信が採用にも確実に手応えをもたらしていると感じています。 今後の展望 # 5周年の節目を迎え、現在デベロッパーサイトはリニューアルに向けて動き出しています。より読みやすい、モダンなサイトへと生まれ変わる予定です。多くの読者にとって「最もノイズが少なく、技術情報に集中できるUI」を目指し、記事ページの可読性向上や、ダークモードのネイティブ対応も計画しています。実装プロセス自体も最新のAI駆動開発（AI-Driven Development）で進めていきます。サイト自体を「生成AIを実践投入するための社内プロジェクト」として位置づけることで、これまで積み重ねてきた生成AIとの歩みをさらに一歩進めたいと考えています。 内容についても、さらなる充実を目指し、開発系の Tips はもちろんのこと、ロボティクスや生成 AI など我々が取り組み、また読者の皆様も興味を持つであろう内容を充実させて行きたいと考えています。アドベントカレンダーや夏のリレー連載、春の新人向け連載といった恒例企画も継続し、まだ執筆デビューしていないメンバーが筆を執るきっかけを作り続けていきます。また、英訳・中国語訳記事の拡充を通じて、国内にとどまらず海外のエンジニアにも豆蔵の技術発信を届けていきたいです。 次の5年、10年先も「開発に役立つサイト」として、そして豆蔵という会社の技術力・人となりが伝わるメディアとして育てていきたいと考えています。 さいごに # 以上、豆蔵デベロッパーサイト5周年の振り返りでした。改めて振り返ってみると、立ち上げ当初2名だった執筆陣が83名まで広がり、900本を超える記事が積み上がったことに、感慨深いものがあります。ここまで続けてこられたのは、折にふれて記事を書いてくれた執筆者の皆さん、そして何より読み続けてくださっている読者の皆さんのおかげです。この場を借りて御礼申し上げます。 6年目以降も、変わらず技術と現場のリアルを発信するメディアであり続けたいと思います。引き続き豆蔵デベロッパーサイトをよろしくお願いいたします。 よかったら フィード の購読、 X や Bluesky でのフォローもお願いします。 Facebook でも本サイトの注目記事をはじめ豆蔵に関するイベントを紹介しています。 note にも時々本サイト関連の記事が掲載されています。