はじめに 本イベントについて 登壇内容の解説 他の方のLT登壇 まとめ はじめに 今年はまだ1回もK-POPのライブに行けてない、楽楽債権管理チームの冨澤です。 3月末に行われたサイバーエージェントさんとOpenAI Japanさんが主催するCodex Userコミュニティイベントで、LT登壇をしてきました！ cyberagent.connpass.com 本記事ではLT内容の解説と学んだ内容をお届けします。 本イベントについて OpenAIのコーディングエージェントである「Codex」に関連する発表を通じて、実践知の共有を行うことが目的のイベントです。 詳細や登壇資料はこちらからご覧ください。 イベント資料一覧 登壇内容の解説 まずは私のLT内容の解説から。 資料はこちら↓ speakerdeck.com 詳細はスライドに譲りますが、チーム内で比較的実装が簡単なCRUD API 5本をCodex CLIでどう実装できるだろう、という疑問から検証を始めました。 実は既に他のコーディングエージェントを利用して同様の検証を行なっていたんですが、Codexの強みや違いなどを明確にし、開発時におけるより適切なツールの選択や運用ができるのではないかとも考えていました。 スライドの最初の失敗から学んだこと、改善、運用の工夫の大部分は、特定のコーディングエージェントに限らない内容だなと、検証を通じて理解することができました。 特に「明確な完了条件」は自己ループ的にエージェントが改善できるようになるので、必須で取り入れるべき工夫だと感じました。この工夫の前後だと全く違う品質のアウトプットが出てくるので、まだ違いを感じたことのない方は是非試してみてください。 コンテキストエンジニアリング本の第3章の指示プロンプト開発の基礎にも同様のことが書かれており、私はこの内容を参考にプロンプトを考えていました。 他のコーディングエージェントとの違いは、承認系で顕著に見られました。 Codex CLIはapproval_policyやsandboxの思想が操作感としても表れており、ここは苦戦しました。個人的にCodexは与えられた閉じた環境で大活躍する性格かなと感じています。 今回は検証利用だったので都度承認を行いましたが、例えばこれがもっと並列数が増えると開発や管理が難しくなるので、設定も含め開発環境整備は必須事項だなと思いました。 またSubAgentsの動きを細かく確認する目的でCodex appを利用しましたがかなり使いやすく、変にCLIにこだわるより、こうしたエコシステムを上手く活用する方が健全だと感じました。 他の方のLT登壇 まずトップバッターの瀬良さんの発表では、ワークフローを管理するための手段としてSkillを活用した話がありました。（ 事例紹介記事 ） 特定の作業を整理したSkillを用意して、適切なタイミングで呼び出すことで小規模な改善をより迅速にリリースできるようになったそうです。 実は今回の自分の検証でもSkillを利用して、実装後のフォーマットやテスト実行、差分比較した上でのレビューまでを一気に行いました。 このように整備しておくことで、Codexが作業を終えた時点である程度の品質を担保できている状態にまで持っていくことができました。この体験が凄く良いです。 また今回は検証できませんでしたが、いずれはAPI実装時は並行してAPIテストを作成することでより良い開発になるのではないかと考えていました。 そしてまさに、瀬良さんも同様の取り組みを行なっており、検証品質向上のSkillを作成してワークフローに組み込んでいるという話もしていました。 SDKとクラウドサービスのバックエンドAPIという少し性質が違う話かと思いますが、自己検証できる材料を丁寧に増やしより品質を高める仕組みを構築する、という観点では同じ考えができるんだなと学びになりました。 他にもKuuさんの確定申告、鈴木さんの開発フロー改善、鷹雄さんのサイバーエージェントさんでのCodex導入についての話があり、丁度自分の情報収集の仕組みや、個人開発の進め方、加えてラクス社内のAI活用が上手な人の事例をもっと知りたかったので、様々な視点での発表がとても学びになりました！ まとめ 今回の検証で、Codexはローカルでインタラクティブに開発を進める形式よりも、クラウドなど閉じた環境を整備し、そこで自由に動いてもらう方が効果を発揮しやすいのかなと感じました。 もちろんCodex appなど他のエコシステムも今後充実していくと思います！どんな進化が待っているか楽しみです！ そして、私にとって初めての外部登壇でしたが、会社からも応援が来ていて大変心強かったです！ 懇親会でお話しした方と経験したことや成功/失敗したことを共有し合えて、登壇以外でも学びになることが多く、チャンスがあれば是非継続していきいたいなと感じました。 スタッフの皆さま、登壇者の皆さま、企画運営本当にありがとうございました！

前回 までは、アウトプットの意義と、日々の仕事を記事にまとめる実践的な方法についてお話ししてきました。ブログで思考を整理し、仕事と発信を1サイクルとして回すところまでお伝えしました。 今回は少し視点を変えます。ブログを書くことに慣れたら、次におすすめしたいのは「別の形でのアウトプット」です。特にここで取り上げたいのは、外部のコミュニティやイベント、カンファレンスでの「登壇」というアウトプットの形です。 記事一覧：【連載】社内外を往復するアジャイルQAの育ち方 【第1回】アウトプットが続かない本当の理由：「完成品」を手放して最初の一歩を踏み出す ［全文公開中］ 【第2回】社内の仕事が記事になる瞬間：実践知を言語化する型と習慣 【第3回】登壇はゴールじゃない：社内実践に効く「外とのつなぎ方」 なぜ外部の場に出るのか ブログのようなアウトプットは、自分の思考を整理し深める点で非常に効果的です。しかし、外部のイベントでは、それとは違う種類の学びが得られます。 外部イベントには、多様な文脈を持つ人々が集まっています。自分の取り組みや学びを発表・共有すると、そこで独特の化学反応が起きます。 一つは、 他者との対話から生まれるフィードバック です。異なる現場の経験を持つ参加者から意見をもらったり、自分が考えてきたテーマについてディスカッションしたりする中で、思いもよらない視点に出会います。「うちのチームでは当たり前だと思っていたことが、他社では珍しい取り組みだった」と知ったときの驚き。「自分たちが悩んでいることは、どこのチームも同じだった」と気づいたときの安堵感。こうした「自分や自社の相対化」は、外の人との対話があってこそ得られるものです。 もう一つは、 情熱を持つ人からの影響 です。あるテーマに真剣に取り組む人と直接話したとき、自分の向き合い方がガラッと変わる瞬間があります。知識を得たというより、何か火がついたような感覚。これは、テキストを読んだり書いたりするだけでは起きにくい種類の変化です。 内と外をつなぐ学びのスパイラル こうした外部イベントでの化学反応は、単発の刺激で終わるものではありません。ここで起きているのは、もっと構造的なサイクルです。 外でアウトプットし、フィードバックを受け、他の実践者から刺激をもらうことで、自分の中に新たな気づきが生まれます。「もしかしたらこういうアプローチもあるのではないか」という仮説が立ち上がる。「あの人がやっていたことを自分のチームでも試してみたい」という意欲が湧く。これまで見えていなかった角度からの洞察が得られる。 そして、その気づきを持ち帰り、自社の普段の業務で新たな実践を行います。その実践から得られた学びをアウトプットし、再び外部のイベントに出て知見を共有する。そこでまた新たな化学反応が起き、さらなる気づきが生まれる。 つまり、 日々の業務での実践 → アウトプットとして言語化 → 外部での共有と化学反応 → 新たな気づき → 実践に還元 というスパイラルが回り始めるのです。一方通行の情報収集ではなく、内と外を往復することで学びが積み上がっていく構造です。 前回お話しした「仕事と発信を1サイクルにする」という考え方に、外部イベントという新たなフィードバックループが加わることで、学びの循環がさらに広がっていきます。外に出る意味は、情報収集や人脈形成だけではありません。この学びのスパイラルを動かすエンジンを手に入れることにあるのです。 QAエンジニアにとっての身近なカンファレンス ブログで思考を整理することに慣れたら、次のステップとしてぜひ外部の場に参加してみましょう。 QAエンジニアにとって身近なカンファレンスといえば、JaSST（ソフトウェアテストシンポジウム）などがあるかと思います。アジャイル開発の文脈では、全国各地で開催されている「スクラムフェス」もおすすめです（私自身はスクラムフェス仙台の運営に携わっています）。中でも「スクラムフェス新潟」はアジャイルテスティングの色が強く、QAの方には特に相性が良いでしょう。 初めての人にとって、外部の人とコミュニケーションをとるのはハードルが高いものです。そこで役に立つのが、すでにブログなどで書いてきた記事です。「こういうことを書いています」「それ読みました！」と話のきっかけにできますし、相手も事前に読んでくれていれば会話が一気に深まります。外部イベントでのコミュニケーションを円滑にするという意味でも、事前のアウトプットは効果的なのです。 もちろん、育児や介護、地理的な事情などで現地参加が難しい場合もあるでしょう。最近は多くのカンファレンスがオンライン参加の選択肢を用意していますので、まずは自分の状況に合った形で参加してみてください。ただ、先に述べた化学反応の強度という意味では、やはり現地での対話が持つ力は大きいと感じています。 登壇への道筋：LTから始める まずは参加することから始めてみてください。セッションを聞く、他の参加者と話す。外の空気を感じるだけでも、先ほどの化学反応は起きます。そうした場でのアウトプットに興味が湧いてきたなら、次のステップとしてぜひセッションへの登壇を目指してほしいと思います。 大きなカンファレンスで登壇している人は華々しく見えますが、彼らも突然その舞台に現れたわけではありません。日々のアウトプットの積み重ねがあってこそ、その場に立っています。小さなアウトプットを継続する中で「アウトプットの筋力」が少しずつ鍛えられ、やがてより大きな聴衆に自分の知見を届けられるようになっていく。ブログもLTもカンファレンス登壇も、すべて地続きの活動です。 こうした舞台に立つことは、キャリアにおいて大きな意味を持ちますし、自信にもつながります。ですが、いきなり大きな場での登壇を目指すのは現実的ではありません。 そこでおすすめなのが、5分程度の「ライトニングトーク（LT）」から始めてみることです。コミュニティイベントやカンファレンスでLT枠があれば、積極的に応募してみましょう。 登壇のネタは、日々のブログの延長線上にあります。ブログがタスクレベルや日々の業務での「小さな気づき」を書くものだとすれば、登壇テーマはもう少し長い時間軸での学びをまとめるものです。プロジェクト単位や、半期・1年といった期間をかけて取り組んだことと、そこでの学びを共有する。私自身は、半年ほどの業務で得た学びを棚卸しする形でプロポーザルを書き、年に2〜3回登壇するというサイクルで活動していました。ブログで蓄積してきた小さな気づきが、こうした振り返りのときに線としてつながります。 いきなり外部のイベントで登壇するのが難しければ、社内勉強会や朝会でのミニLTなど、身近な場から始めてみるのも良いでしょう。「壇上に立って話す」という経験を、小さな場で少しずつ積み上げていきましょう。 外部イベントは「業務」か「プライベートな活動」か 外部イベントへの参加をめぐって、「これは業務なのか、プライベートな活動なのか」という点で多くの人が悩んでいます。業務と認められるかどうかによって、勤務時間内に参加できるか、費用を会社が負担するかが変わってくるからです。事実として、私がカンファレンスで会った参加者の多くは、有給休暇を取り、自費で参加していました。 私の考えはシンプルで、これは「業務」だと捉えています。前回・前々回でお伝えしたように、アウトプットは学びと成長のための営みであり、仕事と地続きのものです。外部イベントへの参加や登壇もその延長線上にある活動です。確かに短期的には通常の業務が止まるためコストに見えますが、変化の速い時代において継続的に学び続けることは、私たちの仕事の本質そのものではないでしょうか。 もちろん、現時点ではそのように位置づけられていない組織の方が多いのが現実です。だからこそ、組織としてこうした場への参加や登壇を後押しする仕組みが必要になります。具体的にどのような制度や文化があれば「個人の根性論」にならずに済むのかについては、次回の最終回で詳しくお話しします。ここでは、外部イベントへの関わり方のグラデーションを整理しておきましょう。 関わり方のグラデーション 外部イベントへの関わり方には、コミットメントの深さに応じたさまざまな形があります。どの関わり方が優れているということではなく、自分の状況や目的に合ったものを選べるのが理想です。 参加者として聴く ：チケットを購入してセッションを聴く、インプットに徹する形です。 積極的に交流する ：他の参加者と話をしたり、ライトニングトーク（LT）をしたりする関わり方です。 登壇者として知見を共有する ：しっかりと準備をしてセッションのプロポーザルを出し、登壇します。参加者たちに知見を共有することで貢献する形です。 協賛（スポンサー）として支援する ：少し経路は違いますが、協賛を通じて間接的に学びを支援することも良い方法です。協賛することでブースの出展やスポンサーチケットが得られるため、複数人のメンバーを参加させることができます。 運営スタッフとして貢献する ：通常参加や登壇とはまた異なる種類の学びが得られます。コミュニティや組織の運営を通じて得た知見は、社内でのチーム運営や組織づくりにも活きてくるため、個人的には非常におすすめです。本連載の本筋からは外れるため詳しくは触れませんが、興味のある方はぜひ一度試してみてください。（参考： スクラムマスター往復書簡 第6回：スクラムマスターにとってなぜコミュニティ活動は重要なのか ） 私自身のマネージャー時代の経験として特におすすめなのは、協賛して数枚の参加枠を確保した上で、「アウトプットに興味はあるけれどイベントにあまり参加したことがない」というメンバーを誘い、2、3人で一緒に参加するという方法です。一人では踏み出しにくいハードルを下げられるというだけでなく、同じ体験を共有することで、イベント後に「あのセッション良かったね」「自分たちでもやってみよう」という会話がチーム内に生まれやすくなります。外の刺激を、そのままチームの中に持ち込めるのです。 この学びのスパイラルが組織全体に広がっていくためには、個人の意欲だけに頼らない仕組みが必要です。次回の最終回では、内と外を往復するこの学びの循環を「個人の根性論」にせず、組織としてどう支えていくかについて考えます。 【連載】社内外を往復するアジャイルQAの育ち方 【第1回】アウトプットが続かない本当の理由：「完成品」を手放して最初の一歩を踏み出す ［全文公開中］ 【第2回】社内の仕事が記事になる瞬間：実践知を言語化する型と習慣 【第3回】登壇はゴールじゃない：社内実践に効く「外とのつなぎ方」 The post 【第3回】登壇はゴールじゃない：社内実践に効く「外とのつなぎ方」 first appeared on Sqripts .

みなさん、こんにちは。ソリューションアーキテクトの川﨑です。この記事では、 富士電機ITソリューション株式会社 が Amazon Q Developer Pro サブスクリプションを活用し、開発者が実施する業務だけではなく日常業務でも生成 AI を取り込むことで、業務効率化のその先にある新しい企業価値の創出へと歩みを進めている旅路をご紹介します。 Amazon Q Developer の新規利用については Amazon Q Developer のサポート終了に関するお知らせ をご確認ください。 富士電機ITソリューション株式会社について 富士電機ITソリューション株式会社（以下、 FSL ）は、システム開発・運用保守・インフラ構築からセキュリティ対応まで、幅広いITソリューションを提供するシステムインテグレーターです。製造・流通・金融・建設など幅広い業界向けの”民需分野”、中央省庁や自治体などの”公共分野”、そして小中学校から大学までをカバーする”文教分野”の 3 本柱で構成され、コンサルティングからシステム設計・開発、ICT インフラ構築、運用・保守までを一気通貫で提供しています。 長年培われた業種・業務ノウハウと、全国規模の顧客基盤を持つ FSL にとって、生成 AI による開発生産性の向上は、自社の競争力強化だけでなく、お客様への付加価値提供を大きく加速する重要なテーマとなっています。 Amazon Q Developer Pro サブスクリプションの展開 FSL では Amazon Q Developer Pro サブスクリプション を 2025年12月に金森 重晴 執行役員 の指揮のもと 20 ユーザーから展開し、現在(2026年4月から)では、50 ユーザー以上へ展開しています。利用場面は、開発現場だけではなく通常業務での活用を推進してきました。導入当初から「まず使ってみる」を合言葉に、各メンバーが自身の業務のなかで生成 AI をどう活かせるかを自律的に模索する文化を育てています。一方的に「こう使ってください」とルールを押し付けるのではなく、自分の業務課題と向き合いながら活用方法を見つけ、社内で事例を共有し合う。このボトムアップ型のアプローチが、想像を超える多様なユースケースを生み出し短期間での利用者拡大を実現できています。勉強会や事例共有会を通して、今後も利用者は拡大していく予定です。 本稿では、2026年4月に実施した Amazon Q Developer ハンズオン勉強会の中でも特に反響の大きかった FSL 社内事例 LT ( Lightning Talk )で共有された 3 名のメンバーの取り組みをご紹介します。 現場から生まれた 3 つの活用事例 事例 1：原田 浩司 氏 – 業務ドキュメント作成の効率化と生成 AI 比較評価 – 原田 氏は、Amazon Q Developer を業務ドキュメントの効率化に活用されています。代表的なユースケースは、 テスト結果報告書の作成 です。これまで手作業で多くの時間を割いていた報告書ドラフト作成を Amazon Q Developer に支援させることで、レビューに集中できる時間が大幅に増えました。作成時のポイントは、HTML出力をすることです。マークダウン形式よりも表現豊かな報告書として出力できるため、作成後の報告にそのまま活用できる点がポイントです。さらに、管理用のExcelレポートへ変換出力をし、業務の効率化をはかっています。説明時に以下のようにコメントされていました。 「Amazon Q Developer の利点である動作しているファイルの読み書きが実行できることで、生成AIを疑問の回答を得るツールではなく、解決策まで実装できる点が使いやすい」 図1:システム試験結果のHTML出力例 図2:システム試験結果のExcel出力例 報告書を作成するだけではなく、障害情報を利用し再発防止策を講じるためのインサイトも生成AIを利用し作成しています。この時の説明時には、以下のようにコメントされていました。 「出力結果も妥当な結果が多く、ある程度の経験者が考えたインサイトと同程度である品質になっている」 さらに原田 氏は、Amazon Q Developer と他の生成 AI　との比較評価にも取り組んでいます。同じタスクを複数のツールで試し、それぞれの強み・弱みを見極めながら「業務ごとに最適な AI を選ぶ」という視点を社内にもたらしています。ツール選定を「感覚」ではなく「実測」で判断する文化は、今後の AI 活用拡大に向けた重要な資産になっています。 事例 2：久保田 匡史 氏 – 開発者業務の生産性を底上げする使いこなし – 久保田 氏は、日常業務の幅広い場面で Amazon Q Developer を使いこなしています。コーディングの枠を超えた特徴的な活用方法を3つ紹介しました。 従来では紙の書類をスキャンした押印画像から、押印部分を透過画像に変換する作業を画像変換ソフトなどを用い数時間かけて作業をしていました。この作業時間短縮のため、 Amazon Q Developer を活用し、画像編集ソフトで手作業していた業務を自動化されています。 続いて、 障害発生時のリスク分析 として、修正前後 ( before / after ) のソースコードを Amazon Q Developer に渡し、「この変更にはどのようなリスクが潜在するか」を問いかけるという、レビュー支援ツールとして利活用できるか検証されていました。人間が特定した原因と同じ問題を、ソースコードと一行のプロンプト”問題があれば指摘してください”だけで特定できたとのことです。この結果を受け、レビュー観点の追加だけではなく、潜在的リスクを早期に検出できるツールとして利用を検討されています。 図3：レビュー支援ツールとしての利用レポート 最後に、 既存プログラムの理解 として、引き継ぎや保守で読み解く必要のあるソースコードを Amazon Q Developer に解説させ、キャッチアップ時間を大幅に短縮されていました。説明時に、以下のようにコメントされていました。 「人間だと理解してドキュメントを作成するために、2週間は必要であった時間が1日で実用レベルのドキュメントを作成することができました。」 図4:既存プログラム理解のレポート 図5:既存プログラムの画面イメージ 久保田 氏の使い方は、「生成 AI はコードを書くためのもの」という固定観念を超え、 開発者の思考を拡張するパートナー として位置付けている点が印象的です。 事例 3：前田 隆憲 氏 – 既存資産の分析から業務ツール内製まで – 前田 氏は、より高度で専門性の高い領域に Amazon Q Developer を活用されています。 ログ／テレメトリーの分析 として、 Amazon Q Developer の利用データを Amazon S3 へ保存する設定をしています。そのため、ユーザー単位で利用状況が csv ファイルとして保存されます。この保存される膨大なログファイルやテレメトリーデータを Amazon Q Developer に読み込ませ、利用状況分析を行っています。 リバースエンジニアリング でも活用されています。既存ソースコードから画面遷移図や ER 図を生成し、ドキュメントが失われた既存システムの保守性を向上されています。また、 プロジェクトルール を活用することで、機能ごとに作成させる設計書のフォーマット統一を図るなど工夫されています。 図6：プログラムから設計書の作成 FSL がソリューションを導入する際の 見積もりツールの開発 にも Amazon Q Developer を利用しています。情報を入力することで、お客様もしくは社内向けに提示する費用を算出することができ、さらに、PDF化することで印刷して見積書としても利用できるツールとなるように開発をされています。 図7：作成中の見積もりツール画面イメージ 前田 氏の事例は、 Amazon Q Developer を「開発の隣にいるアシスタント」から、 業務プロセスに組み込まれたインフラ へと昇華させている点が特徴的でした。 勉強会参加者の声 「事例紹介や演習問題を通して、現在の業務の中で活用シーンはありそうなので、積極的に活用していきます。」 「画面の基本的な利用手順から具体的なチャットへの入力内容を確認できてスタートできそうです。事例では、具体的な入力イメージができました。」 「Amazon Q Developer は、コードを書くときだけでなく、調べる・考える・まとめるといった周辺業務全てに効いてきます。一度使い始めると、もう手放せません」 利用者拡大と Kiro への展開 50 を超えるユーザーでの活用成功と、社内から自然発生的に広がる多様なユースケースを受け、FSL は次のステップとして Amazon Q Developer の利用者数拡大、そして Kiro による次世代の開発体験の取り込みへと舵を切ろうとしています。 Kiro は、仕様からコードまでを一気通貫で扱える、スペック駆動の AI 開発ツールです。Amazon Q Developer で「部分最適」の効率化を積み重ねてきた FSL にとって、Kiro は要件定義から設計・実装・テストまでを横断的に変革する、次なるレバレッジ・ポイントとなります。業務効率化ツールの延長ではなく、 SDLC(ソフトウェア開発ライフサイクル) 全体を再設計する挑戦 が始まろうとしています。 今後の展望：業務効率化から、新しい企業価値の創出へ FSL の旅路は、コーディングエージェントの導入が「開発者の作業を速くする」ことだけに留まらないことを示されていると考えます。今回事例として紹介いただいたものは、 生産性向上に留まらず、自身のお客様へ提供する価値そのものを変えていく動き になっている点が特徴的でした。FSL は今後、Amazon Q Developer の利用者拡大と Kiro の導入も通じて、働き方のイノベーションを起こすことを目指していかれる予定です。生成 AI を導入し利用する本当の目的は、業務や携わっている事業にどのように価値を与えるかにあります。FSL の事例が示すように、現場の一人ひとりが「まずやってみる」を積み重ねることで、自身の業務から事業、さらには、企業全体の変革が形になっていきます。 AWS は、Amazon Q Developer や Kiro をはじめとするコーディングエージェントや生成 AI サービスを通じて、お客様ならではの価値創出の旅路を引き続きサポートしてまいります。生成 AI を活用した開発変革について、ぜひ AWS の担当者にご相談ください。 川﨑 裕希 アマゾンウェブサービスジャパン合同会社のソリューションアーキテクトです。普段は製造業のお客様のご支援を中心に活動しています。IoTやエッジデバイスに興味があり、エッジ推論の検証が最近の趣味です。 <!-- '"` -->