みなさんこんにちは、XI本部エンジニアリングオフィスの佐藤太一です。 このエントリでは、私がRustで実装した Java 用バージョンマネージャであるKopiを紹介すると共に、実装の過程で得た生成AIを使ったソフトウェア開発に関する知見を共有します。 Kopiの ソースコード とドキュメントは全てClaude Codeによるものです。私自身は開発環境の構築とメンテナンスをしながら、プロンプトによる指示のみで、約2か月弱の期間に約四万行のRustコードと約六千行の Markdown を書き上げました。行数の計測においては、コメントや改行は除いています。 成果物は全て オープンソース ソフトウェアとして公開していますので、興味を持ったら是非、公式サイトに来てください。 https://kopi-vm.github.io/ Kopiの紹介 ここでは簡単にKopiを紹介させてください。 Java 用バージョンマネージャとは何か 要はローカルにインストールした複数の Java を必要に応じて切り替えられるソフトウェアのことです。 この手のソフトウェアで私が最初に使ったのは恐らくrvmです。次々とリリースされる Ruby の新しいバージョンに追従するために、気軽に使える インストーラ ーとして使っていたと記憶しています。 今やどの プログラミング言語 にも開発ツールキットを切り替えられるソフトウェアが提供されています。 Python ならvenv、uv、pyenvがあり、Nodeならvolta、nvm、nがあり、様々な言語を統一的に扱える asdf やanyenv、mise、aquaといったツールがあります。 もちろん、 Java にもバージョンマネージャはいくつかあります。jenv、jabba、sdkmanあたりがよく使われているんじゃないでしょうか。 Java 用バージョンマネージャをなぜ新しく作るのか 生成AIに渡す課題として、大きすぎず小さすぎず実用性があり私が作りたいからです。検証課題として、どのようなことを考えていたのかは後述します。 一応、それっぽい説明をしておくと、 Java 専用に作られており、複数のプラットフォームで動作し、メンテナンスが継続しているものがないからです。 jenvやsdkmanは シェルスクリプト の塊なので Windows では動作しません。jabbaはGoで実装されているので複数のプラットフォームで動作しますが、もう何年もメンテナンスされていません。 ちなみに、複数のプラットフォームで動作する様々な言語やツールに対応したバージョンマネージャとしては、miseがあります。 Rustで実装されているmiseは非常に高機能で、複数の言語を管理するだけでなく、 環境変数 をプロジェクトごとに調整しながら、タ スクラン ナーとしても動作します。 Java のバージョン管理機能もコア機能として含まれています。今の時点で、Kopiのmiseに対する優位性は Java 専用の検索機能を提供していることと、再現性のあるフォーマットで詳細にバージョンを指定できることです。 インストール手順 どういうツールなのか分かったところでインストールの方法を説明しましょう。 OSとしては、 Windows 、 Mac 、 Debian / Ubuntu をサポートしています。CPUについては Intel 系とARM系の両方をサポートしています。 Windows11でのインストールは以下のコマンドを実行してください。 winget install kopi macOS でのインストールはHomebrewを使います。 brew install kopi-vm/tap/kopi Debian / Ubuntu はgpgキーのインストールなど少々ややこしいので シェルスクリプト を実行する形式です。中身は自前のPPA リポジトリ から deb パッケージをダウンロードするようになっています。 curl -fsSL https://kopi-vm.github.io/install.sh | bash Rustで実装したツールですので、crates.io にも公開してありcargoでインストールできます。 cargo install kopi 各パッケージマネージャでのインストールが終わったら、setup コマンドを実行します。 kopi setup 必要な ディレクト リが作成されます。続いてshims ディレクト リをPATH 環境変数 に登録するように利用中のシェルに応じて指示が表示されますので、それに従って 環境変数 を調整してください。 例えば、 bash では以下のように指示が表示されます。 基本的な使い方 インストール方法が分かったところで次は基本的な使い方を説明します。 まずは、自分のプロジェクトで使う Java を決めて設定ファイルを作成しましょう。 Kopiは専用の記法で選択的に Java をインストールできます。 # 一番基本的なインストール。この場合ディストリビューションはTemurinになります。 kopi local 21 # ディストリビューションを指定する場合、@の手前にディストリビューション名を指定します。 kopi local corretto@24.0.2 # JRE を指定する事もできます。 kopi local jre@zulu@17.0 これによって、 .kopi-version というファイルが出力されているはずです。例えば、一番上のコマンドを実行した後の中身は以下のようにインストールした Java のバージョンが記載されています。 temurin@21.0.8 この状態で java コマンドを実行してみましょう。以下のように出力されます。 java --version openjdk 24.0.2 2025-07-15 OpenJDK Runtime Environment Corretto-24.0.2.12.1 (build 24.0.2+12-FR) OpenJDK 64-Bit Server VM Corretto-24.0.2.12.1 (build 24.0.2+12-FR, mixed mode, sharing) 今度は Java の ディストリビューション を検索してみましょう。検索もインストールするのと同じ記法が使えます。 kopi search zulu@21 検索結果はこうなります。結果の最上部にあるものが実際にはインストールされるわけですね。2段目以降をインストールしたければ、より詳細にバージョン番号やビルド番号を指定しましょう。 最後は一時的に違うバージョンの Java を使ってみましょう。 kopi shell oracle_open_jdk@21 このコマンドを実行すると、現在使っているシェルの子プロセスとして指定した Java が使えるシェルが起動します。 生成AIを使ったソフトウェア開発 Kopi の基本的な機能を説明しましたので一定の実用性があるソフトウェアであることは、ご理解いただけたでしょう。 ここからは、Kopiをどのような手法で開発したのかを説明します。 KopiはRustを使って実装していますが、全ての ソースコード をClaude Codeが記述しています。改行の一つも私は出力されたものに手を入れていません。 Markdown で書かれたドキュメント類も同様です。 私がこの開発において作業しているのは、開発環境のセットアップ部分です。例えば、Rustの開発環境を構築するための Cargo.toml や rust-toolchain.toml は私が手書きしています。 また、CI/CD環境である GitHub Actionsのワークフローについても私が手書きしています。 GitHub にはコミットしていませんが、開発に使っているDevContainerの構築についても私が用意しました。 Kopiの開発における課題設定 Kopiの開発は実用性があるソフトウェアを、生成AIでどこまで作れるのか？という研究開発の一環で行っているものです。 最終的には、弊社の主たるビジネスである受託開発やパッケージ開発において、生成AIを導入するための足がかりの一部となることを企図しています。 この開発を行うにあたって、最も重要な検証項目はコードを書く作業を一体どこまでなら生成AIに任せられるのか？ということです。 そこで、私自身が取り扱うことの出来ない言語を採用することで手出しが出来ないようにする必要がありました。そのために実装言語としてRustを選んでいます。お恥ずかしいことですが、私自身はどうしても借用の概念が理解できず、いまだにRustを手書きするといつまでたっても コンパイル が通りません。 これは、受託開発やパッケージ開発においてコードを大筋で読むことはできるが書くことは出来ない業務のエキスパートが生成AIを使った場合に、どのような印象を受けるかという視点を模倣したいという意図があります。 生成AIを使った開発の生産性 まずは、分かりやすい生産性指標としての生産コード行数を提示しつつ、この八週間くらいの間にどのような心境の変化があったのか説明しましょう。 ここでは、ノウハウにあたる部分については説明しませんので、読み飛ばして貰っても結構です。 まずは、コードの変更量グラフです。六月の中旬から開発を始めて、約一週間ごとに棒グラフになっています。最初の週が最も生産量が多く約二万行のコードを出力しています。これをピークにその後は徐々に生産量が減っていき、開発がほぼ終了した七月の最終週には一万三千行くらいになっています。 恍惚とした最初の一週間 最初の週はAIハッピーとも言える恍惚とした体験でした。Rustという自分では全く扱えない言語のコードを生成AIが想像を絶する速度で出力していき、それらが全て何となく動いているのです。 私にとって最も得意な プログラミング言語 は Java とTypeScriptですが、それらを使ったうえで働き慣れたプロジェクトで完全に整備された開発環境と疑う余地なく確定した業務仕様が存在するとしても、一週間で二万行のコードを生産することは不可能です。 この時点ではまだ、Claude Codeを使い始めたばかりで、暗中模索といった状況でさえこの量の動くコードが出力されるのですから、プロセスをきちんと整備し私自身が生成AIを使い慣れていけば、一人で月間十万行程度のコードは実装できるのではないかと考えていました。つまり、三か月もあれば三十万行程度のシステムが作れる……。 普通のSI案件なら十人単位の人間が働いてもおかしくない規模感です。そして重要なこととして生成AIに仕事を依頼中は プログラマ の手は空くのです。つまり、PMと一緒になって顧客折衝に参加できます。この時点で私は生成AIの登場によって世界はひっくり返ったと感じていました。 リファクタリング 地獄とプロセス整備の二週目、三週目 夢のような時間は長続きしないものです。 できあがった成果物を冷静になって評価してみると、間違いなく機能しているコードはあるものの、大半はそれっぽく名付けられているのがよく見ると意味不明な関数名やモジュールが一貫性なく定義されており、コーディングスタイルもバラバラです。見せかけだけで何もテストしていないテストコードや何も計測していない ベンチマーク 、そういった実際には役に立たないものが数万行規模であふれていたのです。 二週目と三週目はほとんど機能を追加することなく、コードの整理と名前付けルールの整備、 開発プロセス の整備を行っていました。前の週と違って全く進捗を感じられない低調で辛い時間です。ここで、自らが持つ生成AIに対する過度な期待が打ち砕かれてしまいました。 この時期から、生成AIがある種の コンプリートガチャ （ コンプガチャ ）であると考え始めます。 コンプガチャ とは、複数のアイテムをそろえることで特別な報酬を得られるガチャシステムのことです。2012年ごろに大きな社会問題化し規制されることになりました。 コンプガチャ が規制されているのは、複数のアイテムをそろえることについて人間の認知する確率と実際の確率に大きな乖離があり、その乖離を意識しないままにガチャを回すことに熱狂してしまうからです。 Claude Codeの制約が急にきつくなった四週目 生成AIが コンプガチャ であると考えることで、自分の精神状態がどうなっているのか客観視できるようになります。 ソフトウェア開発におけるコンプリート状態を定義するのは少し難しいものの、全ての機能が手書きしたときと同程度のソフトウェア品質で完成した状態を100%と仮定してみましょう。 コンプガチャ なので、四割から五割くらいまでは比較的容易に到達します。しかし、八割を超えたあたりから急速にアタリの頻度が低減します。 このように考えると、生成AIを使ったソフトウェア開発に対する熱狂と幻滅が起こる原理に近づいている感じがしませんか？ 私が契約しているのはMAXプランの20倍ですが、DevContainerで構築した私の環境ではclaudeプロセスを複数同時に起動していると数分で一つを残してプロセスがシャットダウンされるようになってしまいました（8月現在は、その制限はなくなっているようです）。それまで、常時3つから4つくらいのclaudeプロセスを動かしていたので、成果物の生産量に大きくブレーキがかかってしまいます。ホストOS側の Windows とDevContainer内の二つ同時に動かすことは出来ていたので生産力が激減という程でもなかったのが幸いでした。 プロセスを磨き続けた五週目、六週目 JDK の メタデータ を取得するために使っているFoojayのデータが突然吹き飛んで何もデータが取れなくなるなど、アクシデントはいくつかあるものの順調に開発が進んでいきます。 安定して一万行程度のコードを生産しているように見えますが、実は五週目の中盤から六週目の前半にかけて夏休みをとっていたので、その間は全く稼働していませんでした。 ということは、この時点でかなり生産量が戻ってきているのです。しかし、六週目には当初に予定していた機能の実装が全て完了してしまいます。 生成AIの限界に到達した七週目 八月の第一週は露骨にコードの生産量が低減しています。これはなぜかというと、機能の実装が完了して各OS固有のパッケージングを実装し始めたからです。 例えば、 Windows では WiX Toolsetを使って msi に実行バイナリをパッケージングしています。まず、 Wix という語がインターネット上では二つの全く違うものを指しています。一つは Visual Studio から分離した インストーラ ーの作成ツール、もう一つはWebサイトを簡単に作れる Wix .com という SaaS です。 検索エンジン で知識を収集すると一定の混乱があるわけですね。このような状況では生成AIはほとんど機能しません。話を難しくする状況として、広く使われている WiX Toolsetはv3ですが、v4で大きな変更があった後、急速にバージョンアップが行われておりv3とv4のメンテナンスが終了し、現在はv6が最新です。公式のドキュメントは比較的充実していますし、 MSDN にもドキュメントはそれなりに存在するのですが、生成AIにとって都合の良い形をしていないようです。 どうしてもv3対応の構成定義をしてしまいv6でビルドしようとしてエラーになる。細かく指示を出してv6の記法を使わせても、少しでも曖昧な指示をするとv3の記法を混ぜ込んでしまうことで混乱し、ビルドが失敗するようになる。こういうことを繰り返すので全く進捗しなくなってしまいました。 結果的に、 Wix Toolset、Homebrew、nfpmを用いた構成定義と、それらを GitHub Actionsでパッケージングするワークフローは私が手書きしています。 見積り精度に現実味がでてきた八週目 パッケージングの動作確認としてインストールテストをしている最中に、比較的大きなバグを見つけてしまいました。八週目で突然コードの変更量が一万行にも及んでいるのは、このバグに対応する作業を実施したからです。Kopiは macOS でも動作するのですが、私が macOS を普段使いしていないために、Application Bundleという ディレクト リ構成に関する知見がなく、それを反映したアプリケーションの実装になっていなかったのです。 しかし、ここまでに蓄積した 開発プロセス に基づいて、技術調査、機能設計、実装計画の立案という流れが安定していたので淡々と機能実装を進められました。 生成AIを使った 開発プロセス ここからは、この八週間で得た生成AIを使ったソフトウェア開発において私が蓄積した知見を説明します。 成果物の出力は基本的に英語でやるべき 生成AIが持っている知識や情報の検索処理は基本的に英語で実施されているようです。 生成AIの出力成果物であるドキュメントや ソースコード 、プロンプトの応答はコンテキストの永続化モデルです。 つまり、出力成果物は英語にしておくと翻訳タスクが実行されない分コンテキストウィンドウの消費量を低減し、処理効率の改善が見込めます。 生成AIは出力したものの中身を理解してないと考えるべき 生成AIの仕組みとして、コンテキストウィンドウに蓄積した情報に乱数を混ぜつつ、蓄積している断片的な情報を組み合わせて出力を行います。 つまり、出力したものの整合性が取れているかどうかは、現状だとほぼ検証されていません。 よって、生成AIが何かを出力したら、出力されたコードなりドキュメントなりを検証してフィードバックを返す必要があるのです。 フィードバックを生成AIに返す一番明確な方法は人間が出力成果物を理解したうえで、プロンプトによって伝えることです。 しかし、これは人間のレビュー速度が生成AIが成果物を出す速度を上回る必要があり、現実的には持続可能性がありません。 加えて、生成AIが出す8割の成果物はほぼ意味のないものです。人間は意味のないものを無限にレビューし続けることはできないでしょう。 幸運なことにソフトウェア開発には、これまでの技術的蓄積としてレビューを自動化するための仕組みが多数存在します。 それが、 継続的インテグレーション です。現代的な プログラミング言語 には、必ずコードフォーマッタやLinter、 コンパイラ などの自動的にコードの不備を指摘するためのソフトウェアがそろっています。もちろん、自動化された ユニットテスト や 結合テスト 、E2Eテストも成果物の妥当性を生成AIに伝える良い手段になります。 これらを使って生成AIが出力した成果物を自動的に検証し、無意味なものを人間がレビューせずに済む環境を構築しましょう。 要件定義→外部設計→作業計画の流れを作るべき 自然言語 を使ってコンテキストを構築する以上、生成AIを使ったソフトウェア開発においても、これまで私たちが蓄積してきたノウハウはそのまま適用可能です。 Claude Codeのコンテキストウィンドウには二十万 トーク ンという明確な制限があります。これを実作業に照らし合わせて考えると、おおむね30分～60分程度で実施できる作業範囲内に収まる情報量です。人間に比べるとあまりにも少ないですね。 つまり、生成AIに対して指示を出すにあたって、作業範囲に関する知識はできる限り小さく集約されており、一貫性があり、正確で再現可能なものであることが望ましいということです。 これは、プロンプトを記述する人間に求められる最も重要な技能です。自らの指示が、どういう意図で何をやりたいのか、作業の完了や完成をどのように定義するのかを 言語化 できると、生成AIが作り出す成果の精度が向上します。 例として、直近で私がそれなりに難しいタスクとして実装したApplication Bundleに関連する実装作業について確認してみましょう。 まず、私自身が macOS 用のインストールテストを実施している際に発見した奇妙な状況をClaude Codeに共有し、それがどういうものであるのかをplan-modeで説明してもらいました。 いくつかの質問と応答の後、その状況がApplication Bundleという仕様に基づくものであり、私が奇妙だと感じたものが、実は macOS においてはきちんと仕様化されたものであることが分かります。 そうして生成AIと私が議論した結果をArchitecture Decision Record（ ADR ）として記録したものがこれです。 ADR-018: macOS JDK Bundle Structure Handling これによって、Application Bundleに対してKopiではどのような方向性で対応を行うのかが決まりました。 次はこれを使ってどのように実装するのか機能仕様をDesignDocとして記述してもらいます。 ここで、自分が生成AIに対して期待していることを余すことなく 言語化 します。要求の中で曖昧な部分や矛盾している部分を消し込んでいくために、出力されたDesignDocをレビューします。なお、Claude Codeは ソースコード で説明しようと試みることがありますが、これを承認すべきではありません。 macOS JDK Bundle Structure Handling Design 満足のいくDesignDocになったら、次は作業計画の立案です。 macOS JDK Bundle Structure Implementation Plan 作業計画書のフォーマットにはいくつかポイントがあります。 フェーズ分けをすること。各フェーズの切れ目では /clear コマンドによってコンテキストをクリアすることをプロンプトの中で宣言すること。 各フェーズで入力となる成果物を明記すること。 各フェーズで行うタスクの一覧は更新可能な チェックボックス で構造化し、作業状況の進捗に応じて作業計画を更新させること。 各フェーズでの作業成果物を明示するか、作業完了をどのように確認するか明記すること。 各フェーズは30分～60分程度で終わる粒度になるよう調整すること。長時間のタスクを現在の生成AIでは実施できません。 こうすることによって、生成AIが各フェーズ内において必要十分な情報をコンテキストに読み込んだうえでコードの生成を行うようになります。 作業計画の立案が終わったら、 /clear コマンドでコンテキストをクリアし、 @docs/tasks/ap-bundle/plan.md のフェーズ1を実装してください のような形で指示を出します。 出力された ソースコード を確認して、微調整をしたらフェーズの完了確認のために、自分でコミットをします。 私の場合は、生成AIに対しては基本的に読み取り以外のgit操作をさせないことにしています。それは、おおむね一発で精度の高い成果物を出してくるわけではないからです。細かい調整をしながら --amend コミットをしても良いのですが、そうするくらいなら最初からコミットさせない方が良いという判断を現在はしています。 CLAUDE.md には以下のような記載があり、ほとんどの場合では、フォーマッターやLinter、ユニットや 結合テスト を実行するのですが、コンテキストに余裕がなくなってくると、生成AIがそれらを実施しないことがあります。 ## Development Workflow ### Completing Work When finishing any coding task, always run the following commands in order and fix any issues: 1. ` cargo fmt ` - Auto-format code 2. ` cargo clippy --all-targets -- -D warnings ` - Check for linting errors in test code 3. ` cargo test --lib --quiet ` - Run unit tests (faster than full test suite) Address any errors from each command before proceeding to the next. All must pass successfully before considering the work complete. 実施していない様子が見えたときには、カスタムスラッシュコマンドとして /finish というコマンドを定義していますので、これを実行します。 https://github.com/kopi-vm/kopi/blob/v0.1.3/.claude/commands/finish.md 現時点では、生成AIの技術進歩や新しい技法の発見速度が非常に速いので、あまり多くのカスタムスラッシュコマンドを作りこんでしまわないようにしています。 ここで紹介したやり方は、 Amazon のKiroと概要レベルでは非常に似通っていますが、ある程度の規模でAI駆動開発を行おうとすると、誰もが同じやり方に到達するのでしょう。ドキュメントを読む限りでは、Kiroの方が洗練されたやり方のように感じられます。私自身はKiroをまだ試せていないのですが、今後取り入れていきたいと考えています。 まとめ このエントリでは、生成AIの一つであるClaude Codeを使って実装した、 JDK のバージョンマネージャであるKopiを紹介しました。 この約二か月間の間に起きた私の 心理的 変化について、皆さんに共有したのは今の生成AIブームがある種の熱狂を生んでいると感じているからです。個人的には、15年から20年ぶりの技術的な熱狂を感じながら生成AIを触っています。 この新しい道具が一体どこまで成長し、私たちの仕事や社会を変化させるのか、一緒に楽しんでいけるなら幸いです。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @sato.taichi レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

ここでは、 電通 総研のCAEソリューションビジネスを紹介します。 CAEって何？なにを売っているの？どんな仕事をするの？といった疑問にお応えするため、実際の業務内容を通じて、CAEの魅力とやりがいを伝えたいと思います。 目次 CAEとは？ 電通 総研のCAEソリューション CAEの事例 技術者としての成長 まとめ CAEとは？ シミュレーションと聞いて、何を思い浮かべますか？ 津波 や 地震 の被害予測、ゲーム、天気予報など様々ありますが、一般には現実の現象をデジタルで再現することを意味します。 製造業の世界では、製品を試作して実験する代わりに、CAE（ Computer Aided Engineering ）と呼ばれるシミュレーション技術の適用が年々拡大しています。 CAEは、単に計算することではなく、製品の設計や開発を支援するために、コンピュータ上でシミュレーションを行い技術的な判断をすることを意味します。 設計開発にCAEを適用することで得られる大きな価値は 「実際に物がなくても設計や開発ができる」 ことです。 試作と実験を中心とした製品開発は、性能を満足するまで何度も繰り返す必要があり、コストも時間もかかります。 CAEを活用すれば、試作回数を減らして開発効率を大幅に向上させることができます。また、設計の初期段階で複数の案を比較したり、従来では困難だった複雑な構造や形状の検討をしたりすることも可能になります。 電通 総研のCAEソリューション 電通 総研は設立以来約50年、日本国内のCAE普及に努め、自動車、航空、電機精密、重工など様々な業界のお客様に対してCAEの活用支援を行っています。 CAEツールの販売、サポート、技術 コンサルティング を中心に関連するソリューションの提供を行っています。 特に設計開発の期間短縮、効率化、省力化等の要望に対しては、 クラウド の高性能な計算リソースを使用したり、CAEの自動実行やデータ管理を行うシステムを提供したり、AIを活用する等の多方面からの支援を行っています。 CAEの事例 CAEの事例として「ギアケース騒音対策」と「 ハンズフリー ドアオープナーの構造解析」の2つについて紹介します。 ギアケース騒音の対策検討 概要 ギアの噛み合いを起点とする騒音の問題に対して、CAEでそのメ カニ ズムを明らかにして対策を検討しました。 解析手法 ギアの回転動作、構造の振動、周囲への放射音を計算するため、機構解析、振動解析、音響解析を用いて、現象を再現しました。 対策検討 放射音解析結果に対して周波数分析を行うことで、複数のギア噛み合い成分が含まれていることが分かりました。 その中で最も支配的な、1列目と２列目のギア嚙み合い２次成分である1545Hzに着目して対策を検討します。 1545Hzの放射音について、その伝達メ カニ ズムを分析すると、ケース側面部位の寄与が大きいことが明らかになりました。 このため、この部位の構造に対して振動しにくいように設計変更を行うことで、騒音の低減を行うことができます。 ハンズフリー ドアオープナーの構造解析 概要 2020年から流行した 新型コロナウイルス 感染症 の 接触 感染防止策として、手のひらを使わずにドアノブを引き開ける ハンズフリー ドアオープナーがあります。 ハンズフリー ドアオープナーには、使いやすさ、強度、軽量化が求められるため、CAEでの事前検証を行い、 3Dプリンター で実物を作成しました。 設計検討 腕でドアを引き開ける際に、スムーズな使用感を実現するため、腕が当たる部分の長さや角度を変えて多数の形状パターンを検討しました。 最終的には、どの角度から腕を入れても痛くないよう丸みを帯びた形状を採用し、腕を引っかける部分はドアを開くときには滑らないようにフィットしつつ、腕を抜くときには邪魔にならない長さと角度に設計しました。 設計案に対するCAE評価 設計案の形状に対して、CAEで様々な使用条件を与えて破損しないことを確認します。 最適形状の検討 さらに初期設計案に対して、ラティス構造を適用して、設計最適化のCAE検討を行いました。 最終設計案では、軽量化を実現すると共に、変形量の低減、強度の向上が得られました。 まとめ ハンズフリー ドアオープナーの設計にあたり、CAEを用いた最適化解析を行いました。 結果として、初期設計案に対して、軽量化、変形量の低減、強度の向上を実現する形状を設計し、 3Dプリンター で作成しました。 AIの活用 CAE サロゲート モデル 従来のCAE評価を代替できるAI予測モデルです。 計算時間かかるCAEプロセスを数秒～数十秒で実現できます。 Generative Design 形状生成AIと サロゲート モデルを組み合わせた先進的な自動設計AIソリューションです。 設計仕様を入力すると、制約条件や トレードオフ 等を満たせる設計形状案を複数提示します。 対話的なやりとりで、設計者のエンジニアリング判断をサポートします。 技術者としての成長 二つの成長要素 CAEソリューションを担当するにあたって、”CAE自体の技術力”と”プロジェクトマネジメント力”が求められます。 電通 総研では、この二つのチカラを身に付けて成長することができます。 技術者としての能力/守備範囲を広げられる お客様の課題をCAEで解決するためには、その領域の技術理解とCAEツールを使いこなすスキルが必要となります。さらには、製造業のお客様がどのような業務をしているのか、その内容への理解も欠かせません。 製造業での実務経験がなくても、社内でサポートし合える体制があり、仕事をしながら覚えていくことができます。 また、多種多様な業種のお客様を支援するため、様々な分野の幅広いCAE技術を習得し、さらにはCAE周辺の技術分野にも能力を拡げることが可能です。 * プロジェクトを前に進める力が身につく 現場では、お客様、協力会社、社内の多様な相手と連携しながら業務を進めています。 複数の関係者と連携して課題を整理し、進捗を管理しながらゴールに向かって導く。CAE活用支援の一連の流れの中で、自然とプロジェクトマネジメントのスキルが磨かれていきます。 人と人とをつなぎながら、プロジェクトを前に進めるための能力は、まさにプロジェクトマネジメントのチカラです。 まとめ 電通 総研のCAEソリューションは、最先端のシミュレーション技術で“未来を予測”し、ものづくりの可能性を広げていきます。 航空・自動車・家電など幅広い業界を支え、複雑な課題に挑む多彩なツールと技術が我々にはあります。 若手も第一線で活躍し、仲間と共に挑戦しながら成長できる環境が魅力です。 あなたの好奇心と探究心が、社会を変える一歩になります。 技術で世界を動かす、そのスタートがここにあります。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @moriguchi.kota レビュー： @yamada.y （ Shodo で執筆されました ）

はじめに こんにちは、クロス イノベーション 本部エンジニアリングテク ノロ ジー センターの小澤英泰です。 Claude Codeなどのコーディングエージェントをgit worktreeを使って並列実行している方も多いのではないでしょうか。 これまではgitコマンドや サードパーティ 製の VSCode 拡張機能 を利用してworktreeを管理するのが一般的でしたが、 VSCode 2025年7月版（version 1.103）から標準でgit worktreeの管理機能がサポートされました。 これにより VSCode の GUI で直接worktreeを管理できるようになり、複数のブランチでClaude Codeを同時に実行することが容易になりました。 本記事では、 VSCode の GUI でworktreeを作成し、Claude Codeを並列実行する手順を紹介します。 前提 VSCode のversionが1.103以上であること VSCode の設定のgit.detectWorktreesが有効であること worktreeの作成 VSCode でgit リポジトリ を開く worktreeの検証用ブランチ（worktree/a、worktree/b）を作成 サイドバーのソース管理を開く 該当の リポジトリ の「･･･」を開く 「Worktrees」を展開し「Create Worktree」をクリック 作成済みのworktree/aブランチを選択 worktreeのパス指定 worktreeを1つ作成できました。 上記ステップ4~8をworktree/bブランチでも同様に実施します。 worktree-aとworktree-bの2つのworktreeを作成できました。簡単ですね。 次はworktreeごとにウィンドウを開きます。 worktree-aの「･･･」を開く 「Worktrees」を展開し「Open Worktree in New Window」をクリック worktree-a用のウィンドウが準備できました。 上記ステップ1~2をworktree-bでも同様に実施し、worktree-b用のウィンドウを別で開きます。 以上で2つのworktreeを作成できました。また、別々のウィンドウを開くことで同時作業可能な環境が整いました。 worktree作成時の注意点 worktree間のファイル共有 .gitignore に含まれるファイルはworktree間で共有されません。envファイルのコピーや依存関係のインストールは各worktreeで実行してください。 DevContainerの利用 DevContainer上で開発し、remoteUserをroot以外に指定した場合、worktreeの作成が権限不足で失敗します。 git worktree add /workspaces/vscode-git-worktree.worktrees/worktee-a worktee/a Preparing worktree ( checking out ' worktee/a ' ) fatal: could not create leading directories of ' /workspaces/vscode-git-worktree.worktrees/worktee-a/.git ' : Permission denied 下記で所有者を変更後、worktreeを作成し直してください。 sudo mkdir -p /workspaces/vscode-git-worktree.worktrees sudo chown -R $( whoami ) : $( whoami ) /workspaces/vscode-git-worktree.worktrees Claude Code の並列実行 Claude Codeの実行は通常通りです。各worktreeでClaude Codeを起動して「1. Yes proceed」を選択するだけです。 以降、各worktreeのウィンドウで、Claude Codeを並列実行することができます。 worktreeでのコード変更の見え方 コミット前にworktreeを削除すると変更内容が失われるため、生成したコードは忘れずにコミットしましょう。 worktreeを利用するとコード変更の見え方が若干変わります。各worktreeのウィンドウでコミットする方法が安全そうですね。 各worktreeのウィンドウでコミットする場合、通常のコミット操作と同じです。 mainのウィンドウからコミットする場合、変更のエリアに複数のworktreeでの変更が表示されるので適切に選択しましょう。 worktree-aのウィンドウ worktree-bのウィンドウ mainのウィンドウ worktreeの削除 最後にworktreeの削除方法を説明します。削除前に変更がコミット済みであることを確認しましょう。 mainのウィンドウに戻る サイドバーのソース管理を開く 削除対象のworktreeの「･･･」を開く 「Worktrees」を展開し「Delete Worktree」をクリック 以上でworktreeを削除できました。 さいごに 本記事では、 VSCode の GUI でworktreeを作成し、Claude Code を並列実行する方法を紹介しました。 VSCodeのgit worktreeサポートのIssue は2019年に作成されていましたが、2025年に実装された待望の機能です。 VSCode のgit worktree管理機能とClaude Codeで、より良い開発者体験を実現しましょう。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @ozawa.hideyasu レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

こんにちは、スマート ソサエティ センターの飯田です。 スプレッドシート でAI関数がGAになりました これは、 Excel 関数と同じようにGeminiに対してプロンプト指示を出せる、 Google スプレッドシート の関数になります workspaceupdates.googleblog.com 生成AIによって非構造データを構造データに変えていくデモをご紹介できればと思います。 流山市 の議会のオープンデータをつかって、具体的なイメージを持ちやすい ユースケース でご紹介します。 （対象とするデータは、オープンデータを探していたときに偶然見つかっただけで、深い意図はありません） 流山市 の議会オープンデータについて https://www.nagareyamagikai.jp/opendata/ 流山市 の議会オープンデータ https://www.nagareyamagikai.jp/doc/2012101100013/ AI関数としてB列に含まれている議案がどのカテゴリに属するものか？を生成AIに分析してもらいます =AI("Classify into the following categories. Population・Households / Transportation・Tourism / Social Security・Health / Education・Culture・Sports・Life / Commerce・Service Industry / Enterprises・Households・Economy / Public Administration / Information and Communications・Science and Technology / Agriculture・Forestry・Fisheries / Energy・Water / Land・Climate / International / Justice・Safety・Environment",B2) B2のセルの内容をみて、下記のような形で分類の分析ができます。 Excel の関数とおなじような形で、 生成AIを呼び出すことができるので、ビジネス職の方も扱いやすいかと思います。 生成AIの処理が逐次的に行われるので、数百行などの、大量のデータを処理するのはなかなか難しいかもしれませんが、データの前処理や簡単な分析作業には十分活用できると思います。 生成AIがなかなか浸透しない・・・とお悩みの声をよく聞きますが、このような形で、「生成AIと気が付かずに、使い慣れたツールに自然と入り込んでいる」というのが、生成AIを組織に浸透させるためのコツなのかな？と感じました。 最後に、 電通 総研では、今回ご紹介した スプレッドシート AIを含む、 Google Workspace（Gemini / NotebookLM）のソリューションを展開していますので、ご興味ある方はこちらもみてみてください！ www.dentsusoken.com 最後まで読んでいただきましてありがとうございました！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @iida.michitaka7b3a3dd24e9c454b レビュー： @nagamatsu.yuji （ Shodo で執筆されました ）

スマート ソサエティ センターの飯田です。 2025年7月31日の Google Cloud公式ブログで、Gemini CLI にカスタムスラッシュコマンド（Custom slash commands）機能が追加されたと発表がありました！🎉 早速、この機能を触ってみたいと思います。 cloud.google.com claude codeでは同様の機能が既にあったので、「Gemini CLI にも欲しいな…」と思っていました。 毎回同じプロンプトを入力するのは少し面倒だと感じていたので、今回のアップデートは嬉しいです！ 設定方法 基本的に公式ブログの手順通りに進めればOKです。 プロジェクトで設定する場合は以下の3ステップです。 Gemini CLI をバージョンアップ プロジェクトのルート ディレクト リに .gemini/commands というフォルダを作成 その中に コマンド名.toml という設定ファイルを追加する 試しに、私がよく行う「コミットメッセージの自動生成＆コミット」をカスタムコマンドにしてみます。 /commit で呼び出せるように、 commit.toml という名前でファイルを作成しました。 私の VS Code の ディレクト リ構成はこんな感じです。 GEMINI.md や specification.md で、あらかじめプロジェクトの概要や方針をGeminiに伝えています。 commit.toml には、以下のようにプロンプトを記述しました。 description="前回Commitとの差分を取得して、コメントを自動生成した上でコミットします。" prompt = """ すべて日本語で実行してください。 Gitの前回Commitとの差分を基に、コミットメッセージを自動生成してコミットまで実行してください。 以下の手順に従ってください： 1. `git status && git diff HEAD && git log -n 3` を実行して、変更内容を確認します。 2. 変更があったファイルや追跡されていないファイルがあれば、`git add`コマンドでステージングします。なければ次の手順に進みます。 3. 削除されたファイルがあれば、`git rm`コマンドで削除します。なければ次の手順に進みます。 4. 過去のコミットログを参考に、Conventional Commitsの規約に沿った日本語のコミットメッセージを提案します。 5. コミットが完了したら、`git status`で状態を確認します。 6. コミットが正常に完了し、作業ディレクトリがクリーンな状態であることを確認します。 Git関連のタスクには、シェルツールを組み合わせてGitコマンド（`git`）を使用してください。 """ 実際にターミナルで実行してみると、こんな感じで日本語でも動作しました。 これまでは毎回長いプロンプトを貼り付ける必要がありましたが、これからは /commit と入力するだけで済むように。 これは便利！ 普段Claude Codeを使っている方も、Gemini CLI を使っている方も、こうしたカスタムコマンドをプロジェクト内で共有しておくと、チーム全体の開発効率がグッと上がりそうです。 ぜひ試してみてください！ 最後まで読んでいただきましてありがとうございました！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @iida.michi レビュー： @takami.yusuke （ Shodo で執筆されました ）

こんにちは。 電通 総研ITの寺尾です。 今回は IntelliJ の コード補完機能 の実装方法についてご紹介します。 前回はこちら： IntelliJプラグイン開発の始め方～コード検査編～ コード補完とは Java で 予約語 や変数名などを記述する時、「Ctrl + Space」でIDEAから提示される候補から選択するという操作はよくされると思います。 近年では、AIによるサポートで入力候補が提示される機能もよく見かけるようになりました。 そのように提案（サジェスト）されるリストを、 プラグイン の コード補完機能 として実装することができます。 実装前に知っておくこと 前回と同様に、本記事でもKotlinでの実装例を提示します。 Kotlinプロジェクトに関する内容は、アクション機能編の 実装前に知っておくこと をご参照ください。 実装 ゴール 今回は、 Doma のディレクティブ内でDAOメソッドで定義されたパラメータをサジェストする機能を実装してみます。 事前準備 IntelliJ に指定の言語に対するコード補完機能として認識させるための設定と、実装クラスを用意します。 「 Doma Tools」では、 SQL をカスタム言語として扱っているため、独自の言語IDとコード補完クラスを紐づけています。 まずは以下の準備から始めていきましょう。 CompletionContributor のサブクラス CompletionProvider のサブクラス プラグイン 設定登録 コード補完機能ではコントリビュータクラスを登録し、カーソル位置が特定の条件に一致する場合にプロバイダークラスを呼び出す処理を行います。 plugin.xml には、以下のように <completion.contributor> タグを使ってコントリビュータクラスを登録します。 コントリビュータクラスは IntelliJ の拡張ポイントとして登録するため、 <extensions defaultExtensionNs="com.intellij"> タグの中に記述します。 <completion . contributor language = "DomaSql" implementationClass = "org.domaframework.doma.intellij.contributor.sql.SqlCompletionContributor" order = "first" /> 各実装のポイントを以下で解説します。最後に「 Doma Tools」 リポジトリ の実装コードのリンクも添付していますのでご参考ください。 コントリビュータクラスの実装 コード補完を呼び出した時のカーソル位置が、条件に合う場合にのみコード補完を呼び出すように制御します。 このコントリビュータクラスでは、 extend() で条件判定の処理を呼び出し、最後に条件に一致する場合のプロバイダークラスを設定します。 以下の例では、独自に要素チェックを行う PsiPatternUtil を実装し、各メソッド内で判定処理を実装しています。 open class SqlCompletionContributor : CompletionContributor() { init { extend( CompletionType.BASIC, // コード補完タイプ。今回は通常のコード補完呼び出しで実行するためBASICを指定 // コード補完を呼び出す条件を定義 PsiPatternUtil .createPattern(PsiComment :: class .java) .andOr( // 独自の処理で要素のパターンをチェック PsiPatternUtil .createPattern(PsiComment :: class .java) .inFile( PlatformPatterns .psiFile() .withLanguage(SqlLanguage.INSTANCE), ), PsiPatternUtil .createPattern(PsiComment :: class .java) .and(PsiPatternUtil.isMatchFileExtension( "java" )), ) ), // パターンと一致する場合に呼び出すプロバイダークラスインスタンス SqlParameterCompletionProvider(), ) } } プロバイダークラスの実装 コード補完の本体処理を担当する CompletionProvider を実装します。 プロバイダークラスの役割は、サジェスト情報を収集してリストをセットすることになります。 オーバーライドメソッド addCompletions() を実装し、カーソル位置の要素をチェックしてサジェストリストを生成します。 override fun addCompletions( parameters: CompletionParameters, // カーソル位置の情報など context: ProcessingContext, result: CompletionResultSet, // サジェストを登録するリスト ) { // サジェスト情報を収集するロジックを実装 // resultにサジェストオブジェクトを追加 } サジェストオブジェクトの生成と登録 サジェストしたい情報の型によって、 result にセットする際に工夫が必要になります。 例えば、クラスのフィールド（PsiField）オブジェクトは以下のように VariableLookupItem への簡単な変換で追加ができます。 // フィールドをリストに登録 // VariableLookupItemにPsiFieldを渡したオブジェクトを生成しリストに追加 result.addAllElements(filterFields.map { param -> VariableLookupItem(param) }) 対して、メソッド(PsiMethod)や独自の型からサジェストオブジェクトを生成する場合は、以下のように各パラメータをセットしたビルダーを使用します。 // LookupElementBuilderでサジェスト情報を設定したオブジェクトを生成する filterMethods.forEach { method -> val lookupElm = LookupElementBuilder .create(method.name) // 候補名を設定 .withPresentableText(method.name) // 補完決定時に入力する文字列を設定 .withTailText(method.parameterList.text, true ) // 補足情報にメソッドのパラメータ情報を設定 .withTypeText(method.returnType?.presentableText ?: "" ) // 候補の型情報を設定 .withAutoCompletionPolicy(AutoCompletionPolicy.ALWAYS_AUTOCOMPLETE) // ALWAYS_AUTOCOMPLETE:候補が1つだけの場合自動で補完する // 生成したLookupElementBuilderを登録 result.addElement(lookupElm) } result.addElement() によって、サジェストリストへの登録が完了します。 動かしてみる 実際にコード補完を呼び出し、取得した情報がサジェストされることを確認してみましょう。 デバッグ 起動方法は前回と同じく、 デバッグ起動する で実行してください。 参考： 「 Doma Tools」実装コード 「 Doma Tools」のコード補完機能は、以下コードで実装しています。 SqlCompletionContributor SqlParameterCompletionProvider まとめ コード補完機能の実装ポイントは以下3点になります。 コントリビュータクラスで、補完処理の呼び出し条件を適切に設定する プロバイダークラスで、サジェストリストを登録する 不完全な状態の構文を考慮した実装を行う コード補完機能では、入力途中の要素に対して考慮するポイントが多く存在します。 PSI要素の親子関係や要素タイプだけではカバーできないケースにも対応する必要があるため、実装が複雑になりがちな機能だと思います。 そのため、複数のケースで繰り返し使える処理の共 通化 や要素の判定条件の整理が、正確なサジェストには重要になります。 さいごに Doma のように複数のファイルをまたいだ実装を行うケースでは、コード補完によるコーディングサポートによって開発者の負担を大きく軽減できるようになります。 カスタム言語を扱う予定がありましたら、構文やプロパティを適切に記述するための機能として併せて実装してみてください！ Doma Toolsへのレビューも投稿していただけますと大変励みになります🙇‍♀️ Doma Tools マーケットプレースページ 本 プラグイン は OSS として Domaコミュニティ へ寄贈されています。 不具合修正や機能要望、ディスカッションにもぜひご参加ください。 採用ページ 執筆： @terao.haruka レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

こんにちは。 電通 総研に新卒で入社して10年目、現在はロンドン 現地法人 ( DENTSU SOKEN UK, Ltd.)に出向して3年目の竹村です。 社内では少し珍しい“海外赴任組”のひとりとして、ロンドンで働いています。 とはいえ、「絶対に海外で働きたい！」と強く願っていたわけではありません。 きっかけは本当に偶然で、完全に タイミングと運 でこの地に立っています。 なぜ海外赴任に？ 私が所属する金融IT本部は、 グローバルに展開する金融機関のIT部門と一緒に進めるプロジェクトが多く 、海外とのやり取りが日常茶飯事です。海外出張や赴任のチャンスも比較的多い部門だと思います。 実際、私が東京で携わっていたプロジェクトも、 ロンドンにメインの開発拠点 があり、当時からロンドンのメンバーとは毎日のようにやり取りしていました。 そんな中、もともとロンドン常駐だった前任の方が退職されて、 ポジションがぽっかり空いてしまい …。 たまたまそのタイミングで、英語がある程度できて、海外勤務に抵抗がなく、さらに同じプロジェクトのことをある程度理解していたのが、 当時のメンバーの中で私だけだった ...という流れで、そのままロンドン赴任が決まりました。 つまり、「強く希望して海外赴任を勝ち取った！」というよりは、「 たまたまタイミングと条件がハマった 」という感じです。 とはいえ、 弊社には風通しのいい文化がある ので、「行きたい！」と希望を出し続けていれば、 ちゃんとチャンスは巡ってきます 。実際、周りを見ても、 声を上げ続けていた人はみんな出張や赴任で海外に行っている印象 があります。もし 海外勤務に興味があるなら、遠慮せずにどんどん希望を出し続けるのがおすすめ です。 現在の業務について ロンドンでは、某銀行で使われている 外国為替 取引の自動 アルゴリズム 執行システム（通称：EFXシステム）の開発に携わっています。 このシステムは ほぼス クラッチ で作られており、 メインの開発拠点はロンドン 。東京では主に成果物の受け入れテストや周辺機能の開発を担当していて、 ロンドンと東京で連携 しながらプロジェクトを進めています。 銀行の大規模システムとしては珍しく、 アジャイル 開発を採用 しており、 月1回のリリースサイクル で継続的にエンハンスを続けています。 私の役割は、ロンドン開発チームの一員として、 現地のBusiness Analyst （ユーザー部門からの要望をとりまとめて、システム設計に落とし込む人） と連携 しながら 設計を詰め、担当アプリの開発から 単体テスト までをひとりで担当 することです。 最終的には、自分で考えて、決めて、作るというスタイルなので、 裁量も自由度も大きい分、正直、責任もかなり大きいです。 ロンドンでの働き方とカルチャー ロンドンの 現地法人 では、管理やPreSalesを除くと、 基本的にオンサイトサポート。勤務スタイルはお客様のルールに従う形 で、私のお客様先では「週3日出社・週2日リモート」が基本。 定時は9:00〜17:30 です。 ただ、現地の行員の皆さんはあまり定時を気にしていないのか、遅く来る人もいれば、なぜか毎日定時前にさっさと帰る人もいたりして、けっこう自由です。笑（その中でも日本人はしっかり働いていて、定時を過ぎるとオフィスに残っているのは日本人ばかり…というのがいつもの光景です。笑） 業務中はしっかり集中して取り組むものの、 「仕事よりプライベートの方が断然大事」というカルチャーがこちらでは根付いて いて、赴任当初は正直かなり衝撃を受けました。 そのぶん ワークライフバランス はとても良好 で、夏休みやクリスマスには1ヶ月近く休暇を取る人も珍しくありません。 今ではすっかりこのスタイルに慣れてしまい、日本に戻ったときちゃんと働けるか、ちょっと不安です。笑 業務の進め方も日本とはけっこう違っていて、ミーティングは最小限。（みんなミーティングが嫌いなので……） 定例は基本的にデイリー スクラム のみで、それ以外は必要があればその場で声をかけ合って、短時間でサクッと話して終わる、という感じです。 メンバーは それぞれが自立して動いていて 、同じプロジェクトでない限りはあまり関わることはありません。会ったら雑談するくらいです。 一応リーダーはいますが、積極的に指導や管理をすることはほとんどなく、「困ったら助けるよ」くらいのスタンス。なので、かなり各自の自主性に任されています。（そのぶん正直、クオリティにばらつきがあって、若干そこは課題でもあります……） 基本的には「できる人のコードを勝手に読んで学ぶ」スタイルで、 自主性がかなり求められます。 海外で働きたい人に伝えたいこと 海外で働く上で大切なのは、 業務知識や技術といった専門性をしっかり持っていること だと思います。（もちろん、 英語で最低限のコミュニケーションができることは大前提 ですが） 私は東京でEFXプロジェクトにしっかり関わっていたおかげで、ロンドンでも即戦力としてスムーズに受け入れてもらえました。 そしてもうひとつ大事なのは、 「希望し続けること」 だと思います。 （まあそこまで強く希望してなかった自分が言うのもなんですが…笑） 「海外で働いてみたい」と思っているなら、 タイミングはきっといつか巡ってきます。 最後に 海外赴任は、思っているよりずっと現実的で手の届く経験 です。 環境が変われば 働き方も考え方も変わります し、なにより 自分の成長を強く感じられるチャンス でもあります。 私のキャリアが、これから海外を目指す誰かの参考になれば嬉しいです。 日本からのロンドン赴任メンバーで一枚。（一部違う人もいますが…） 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @takemura.masakuni レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

電通 総研のスマート ソサエティ センターの飯田です。 Veo3は Google I/O 2025で発表された動画生成のAIモデルです。 最新の動画生成モデル Veo 3 は、Veo 2 の品質を向上させただけでなく、音声付きの動画生成を初めて実現しました。 テキストや画像によるプロンプト入力から、現実世界の物理法則の反映、正確な リップシンク まで、あらゆる側面で優れた性能を発揮します。理解力も優れており、プロンプトで短いストーリーを伝えるだけで、その内容を鮮明に表現した映像を生成します Imagen 4, Veo 3: Googleの最新のメディア生成モデル とあるように、高品質な動画と音声の生成が可能となっており、コンテンツ制作の新たな可能性が広がっています。 その中の１つの事例として、 Veo3によるASMR動画が流行っています。 たとえば、下のような形で、現実的ではない気持ちがいい動画を生成できます ビスマス 結晶のカット作業 #Veo3 #ASMR pic.twitter.com/FpvURmmVlK — LONPEL (@__LONPEL__) 2025年6月24日 私もつくってみました www.youtube.com （切れると思いきや、切れない） Veo2→Veo3になって進化した品質を比較しつつ、カメラワークのプロンプトエンジニアリングについて触ってみました。 動画におけるプロンプトエンジニアリング Google Cloudから、ビデオ生成におけるプロンプトエンジニアリングのコツがまとめられています Vertex AI 動画生成プロンプト ガイド  |  Generative AI on Vertex AI  |  Google Cloud 以下の点を含めると狙った動画を作りやすいということです。 被写体： 動画に含める物体、人物、動物、風景。 コンテキスト：被写体が配置される背景やコンテキスト。 アクション：被写体が行っている動作（歩く、走る、首を回すなど）。 スタイル：一般的なスタイルでも、特定化されたスタイルでもかまいません。ホラー映画、フィルム ノワール など、特定の映画スタイルのキーワードや、 カートゥーン スタイルの レンダリング などのアニメーション スタイルのキーワードの使用を検討してください。 カメラの動き：省略可。カメラの動作（空中撮影、目の高さ、上からの撮影、低角度撮影など）。 構図：省略可。ワイドショット、クローズアップ、エクストリーム クローズアップなど、ショットのフレームを設定。 アンビエンス：省略可。青色、夜間、暖色など、色と光がシーンに与える影響。 それを参考にベースのテンプレートを作りました。 【主題】一頭の巨大な雄のシャチ。 【場所】氷山が浮かぶ、静かで澄み切った北極の海。 【シーン】 ・シャチが力強く、しかし優雅な尾びれの動きで、冷たい深海を滑るように進んでいく。太陽の光が水中に差し込み、神々しい光の筋（ゴッドレイ）を作り出している。 【スタイル】ドキュメンタリー映画のような、壮大でシネマティックなスタイル。４K高画質のフォトリアル。 【カメラワーク】ゆっくりとパン(pan)する 上記のカメラワークの表現だけを色々変えてVeo2・Veo3で比較してみました。 以下、結果です。 Veo2 www.youtube.com Veo3 www.youtube.com 全体的な印象として、Veo3の高精細かつ、カメラワークも安定している感じがします。 あと、何より、音も付いてくるのが素晴らしいですね。 企業ユースでは、Veo2はVertexAI・ Google AI Studio・Vidsで生成できます。 Veo3はVertex AI、Vidsの Preview 機能、 Google WorkspaceのGeminiで生成できると思います。 （Vidsは現在、英語のみ対応） ちなみに、シャチの動画は、Veo2はVertexAI、Veo3はVidsでプロンプトを英訳して、生成しました。 Vidsは下のイメージの右枠にあるような形で入力できます。 Vidsは簡単な動画作成にも優秀なツールです。 最終的な動画として繋げる部分はVidsを使っています。 まとめ 画像生成も狙った画像を作り出すのは難しいと思いますが、動画生成は狙った映像を作り出すのが画像生成よりも難しいと感じており、色々と試行錯誤をしないと狙った映像にならないなぁという感覚があります。 今回はカメラワークのパラメータを意識して動かすことで、感覚をつかめましたが、カメラ深度やアニメ調など様々な設定があるので、今後、そのあたりも試していきたいと思います。 そして、映像表現の引き出しも持っていないと、そもそもどういう絵が魅力的なのか？とかもわからないので、そのあたりも引き出しを増やせたらと思いました。 最後に、 電通 総研では、今回ご紹介したVidsを含む、 Google Workspace（Gemini / NotebookLM）のソリューションを展開していますので、ご興味ある方はこちらもみてみてください！ www.dentsusoken.com 最後まで読んでいただきましてありがとうございました！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @iida.michitaka7b3a3dd24e9c454b （ Shodo で執筆されました ）

はいどーもー！ 情報処理安全確保支援士試験の午後試験解答かるたが存在したら「く」の札は「クライアント証明書によるデ バイス 認証」ですよね！ エンタープライズ 第一本部の宮澤響です！ 本記事では、私が先日受験した、令和7年度春期情報処理安全確保支援士試験にまつわる体験を共有します。 これから情報処理安全確保支援士試験を受験する方々に向けたアド バイス というよりは、同じ令和7年度春期試験を受験した同志のみなさまと「こんな感じでしたよね！分かる分かる！」と共感し合うような内容ですので、あまり受験対策の参考にはならないかもしれませんが、温かい目で読んでいただけたら幸いです。 前提（受験歴や業務経験など） 試験に向けて 学習期間 学習方法 午後試験の戦略 当日の感想 午前Ⅰ試験 午前Ⅱ試験 午後試験 午後試験問題の振り返り 問1：サプライチェーンのリスク対策 問2：脆弱性管理 合格発表 おわりに 前提（受験歴や業務経験など） ざっくり、以下のような状態でした。 初受験 応用情報技術者試験 合格済み（ただし学生時代のため、午前Ⅰ試験の免除はナシ） CSIRTやSOCのような、いわゆるセキュリティ担当者としての業務経験はナシ 社内インフラの運用・保守のような業務経験もナシ アプリケーション開発は新人研修や業務で少々（そのおかげでセキュアプログラミング問題の ソースコード は読める） 試験に向けて 学習期間 約4か月間（2024年12月中旬〜2025年4月中旬）でした。 なお、1日何時間勉強する、1日何問解く、というようなノルマは設けず、学習時間も特に記録していなかったため、トータルの学習時間が何時間かは不明です。 学習方法 「追加調査」以外はいわゆる王道の学習方法であり、他の合格体験記などでも詳しく述べられていることが多いため、本記事では概略のみ記載します。 インプット： テキスト： ゼロからスタート！教育系YouTuberまさるの情報処理安全確保支援士1冊目の教科書 情報処理教科書 情報処理安全確保支援士 2025年版 うかる！ 情報処理安全確保支援士 午後問題集[第2版] 各種 YouTube 動画 各種 IPA 資料 各種合格体験記 追加調査： 3Dセキュア2.0関連（∵導入義務化が2025年4月からであったため） ランサムウェア 対策関連（∵問題作成時期を考慮すると KADOKAWA の ランサムウェア 被害を踏まえた出題が予想されたため） 地政学 的リスク関連（∵「情報セキュリティ10大脅威 2025」で初選出されていたため） AIセキュリティ関連（∵いつか出題されると言われ続けて未だに出題されていないため） アウトプット： 午前Ⅰ試験対策： 応用情報技術者試験 過去問道場 午前Ⅱ試験対策：情報処理安全確保支援士過去問道場 午後試験対策：過去問（ 情報セキュリティスペシャリスト 試験の過去問には着手せず） 午後試験の戦略 以下のような時間の使い方で午後試験に臨もうと考えていました。 全ての大問を"浅く"解く（MAX 60分（15分×4）） 目的：前半が難しくても後半が易しい（またはその逆の）大問、問題文が難しくても設問が易しい（またはその逆の）大問、などに惑わされずに、"解ける"大問を見抜くため 内容：問題文および設問に一通り目を通し、頭の中で解答のニュアンスを把握（この時点で明らかに解答が判明する設問は、解答用紙に解答を記入） 得点できそうな大問2つを"深く"解く（MAX 80分（40分×2）） 途中退室せず時間いっぱい見直す（MIN 10分） 「全ての大問を"浅く"解く」に関しては、他の受験者の方々とは異なる比較的珍しい時間の使い方かなと思います。 「この分野は絶対解く」「この分野は絶対捨てる」といった明確な得意／不得意分野がなく、文章読解スピードが比較的速い（且つ読解した内容を脳内メモリにキャッシュしておける）方には合うかもしれませんが、向き不向きが激しい戦略のため、万人におすすめはできないかなと思います。 そのため、上記戦略を採用してみたいと考えている方も、まずは過去問などで実際に試してみて、肌に合うか確認してから採用することをおすすめします。 当日の感想 午前Ⅰ試験 私の試験会場の教室では、思っていたよりも午前Ⅰ試験からの受験者が多かったです。 体感としては、受験者全体の7割くらいといったところでした。 初見の計算問題や知識問題がいくつか出題されましたが、出題数としては試験問題全体の1-2割程度であったため、初見問題が全滅だとしても6割を切ることはないなと安心していました。 午前Ⅱ試験 過去問と同一の問題やその類似問題が多く出題され、比較的簡単でした。 そのため、午後試験の倍率が高くなる（採点が厳しくなる）ことを懸念していました。 午後試験 ここからが本番です。 試験開始前、解答用紙が配布された段階では、以下のようなことを考えていました。 字数制限、復活してるじゃん。 大問2の欄に「EPSS値」なる初見の単語があるな…。「現状値」はCVSSだろうから 脆弱性 管理系の大問かな。これは選択しないだろうな…。 大問3の欄にURLを記入する箇所があるな…。開発系の大問だろうからこれは選択しようかな。 そして試験開始後、時系列に沿った頭の中（大問選択に関する考えの移ろい）は以下でした。 まずは大問3を見てみよう。あんまり解けないな…。 TLS 1.3のハンドシェイクの順番なんて暗記してないし、他の大問の方が解きやすいかもしれない。切り替えよう。 大問1を見てみよう。CI/CDパイプライン、耳なじみのある言葉。これは解けそう…！ 大問2、「Attack Complexity」とか「EPSS値」とかって特に注釈ないのか…。厳しそうかな。 大問4、これも管理系か。大問2のように初見の単語はないけど、その分こっちの方が内容はとっつきにくい気もするな…。 さすがにそろそろ深く解き始めないと間に合わないか。 大問3に戻ってきた。 TLS ハンドシェイクも推測である程度は解けそうだが、記号問題で部分点がないからかなりリスキーだな…。他の設問もあまり自信をもって解答できないし、管理系で部分点狙いの方が安定するか…？ 大問2、改めて見ると、最後の記号問題はサービス問題だな。初見の単語は他のほとんどの受験者も初見だろうから国語力や推測力で勝負できそう。ある程度推測でそれっぽいことは書けそうだし、これにするか…！ 大問選択に迷いまくっている様子が伺えますね。笑 正直、頭が真っ白になりかけていて、かなりテンパっていたと思います。 手汗で解答用紙が少しふやけて波打っていたほどです。 試験終了時点では、これは終わったわ…と思っていました。 部署の週報でも「さすがに落ちました」と投稿していました。 午後試験問題の振り返り 改めて午後試験問題を振り返ってみます。 なお、実際に選択した大問は、上述のとおり、問1と問2です。 問題冊子 解答例 採点講評 問1： サプライチェーン のリスク対策 設問1（1）： 「セキュリティ・ バイ・デザイン 」は試験問題としては初出でしたが、 シラバス には記載されていたため、出落ち回避できました。 設問3（2）： このタイプの設問で空欄3つ中2つが「問題なし」になるなんて思わないですよね…！笑 純粋な設問の難易度だけを考えたら決して高くはないんですが、2つも「問題なし」になるわけないよな…？と何度も問題文や図表を見返して解答時間を吸われたのは私だけではないはず…。 ちなみに私は結局bを「問題なし」、cを「問題なし、ただし〇〇することが望ましい」のような解答とし、cの正解が「問題なし」ではなかったときに部分点を1点でももぎ取ろうとする中途半端な解答にしました。 問2： 脆弱性 管理 設問1： 空欄が5つ、選択肢はア〜エの4つ、という状況で、アとイしか使わないなんてことあるのか…？と疑心暗鬼になりつつ解答しました。 設問3（1）： iが曲線、kが鍵長なのは分かるとして、kとjは勘でしたね…外しましたが…。 設問3（3）： クライアント証明書によるデ バイス 認証ォォォ！（冒頭挨拶の伏線回収） 設問4（1）： Attack Complexity、初見だが？？？注釈もないが？？？ シラバス にも載っていなかったが？？？と心の中で叫んでいました。笑 とはいえ、名称的に攻撃の複雑さに関する指標だろうということと、LとHはLowとHighだろうということは十分推測可能な範囲だったため、攻撃者視点で簡単に攻撃できるならL、攻撃が複雑で困難ならH、ということだろうと推測して解答しました。 採点講評でも「正答率が低かった」と書かれていましたね。それはそうです。（？） 設問5（1）： EPSS値、初見だが？？？注釈もないが？？？ シラバス にも載っていなかったが？？？と心の中で叫んでいました。笑 ただ、これも、「CVSS現状値だと手間がかかり、EPSS値だと手間がかからない」ということなので、算出し直したり再評価したりする手間が不要なのかな、といった推測で多少の部分点は稼げたのかなと思います。 採点講評でも「正答率が低かった」と書かれていましたね。それはそうです。（？） 設問5（3）： 問題文の最初の状況説明のあたりにわざわざ「P社のWebアプリ診断は、 脆弱性 が実際に悪用できることを確認したうえで報告してくれるので、評判がよい」と（読み進めるうえでは特に不要そうな評判の良し悪しが）記載されているのは、謎解き的に考えたらさすがに怪しすぎないか？と思っていたので、この設問を見たときにピンときました。 EPSS値のことは分からないながらも、ここは完答できました。 合格発表 記事タイトルのとおりですが、無事に合格していました。 合格できてホッとしていますが、主観として"解けなかった"ことは事実ですので、慢心せず、今後も継続的にキャッチアップを続けていきたいと考えています。 なお、午後試験に関しては、各社の解答速報などを参考に甘めに自己採点した点数よりもさらに上振れた点数であったため、かなり甘めに部分点を貰えたようです。 これは完全に推測ですが、今回に関しては、部分点はほとんどが加点方式で、解答文に多少ニュアンスがおかしい記述が含まれていても、減点はされなかったのかもしれません。 そのため、「若干見当違いな部分や方向性がズレた箇所が混入してもいいから、とにかく分かることや推測できることで解答欄を埋める」、といった姿勢が大事なのかもしれません。 おわりに 本記事では、令和7年度春期情報処理安全確保支援士試験に向けての学習や、実際に受験してみての感想について、共有しました。 本記事をお読みいただいたみなさまの合格を願っています！ 最後までお読みいただき、本当にありがとうございました！ 私たちは共に働いていただける仲間を募集しています！ みなさまのご応募、お待ちしています！ 株式会社電通総研 新卒採用サイト 株式会社電通総研 キャリア採用サイト 執筆： @miyazawa.hibiki レビュー： @handa.kenta （ Shodo で執筆されました ）

こんにちは。 電通 総研コーポレート本部システム推進部の山下です。 この記事は自分が Amazon Q Developer(以降 Amazon Q)の実体験で得た知見を整理したものとなっています。 大体 Amazon Qを使って5-6万行程度のコードを書かせてみて得られた知見となっています。これから Amazon Qを使った開発をしてみたいという方の参考になれば幸いです。 対象読者 以下のことにはある程度慣れている人が対象です VS Code などの IDE やターミナルを日常的に使う Git／CI の基礎を知っている 生成AIについて多少知識がある 生成AIを使ったコーディングエージェント コーディングエージェントって利用されている方、聞いたことがある方も増えてきているのではないでしょうか？ 例をあげると以下のようなツールたちです。 Claude Code Amazon Q Developer GitHub Copilot Agent Gemini CLI IDE と統合されているCursorやClineといったものもありますが、今回のものとは少し異なります。 世の中のブログなどではClaude Codeが話題になっていることが多いような印象があります。 Amazon Q Developer とは さて、今回紹介する Amazon Q Developer(以降 Amazon Q)は、 AWS が提供しているコーディングエージェントです。 利用開始には、アカウントが必要でこのアカウントが少し分かりづらい形になっています。 まず、アカウントの払い出しの方法としては2種類あります。 IAM Identity Center Builders ID IAM Identity Centerの方が機能が多かったりするようです。 コーディングエージェントとして利用する場合には大きな機能の差はありません。 IAM Identity Centerを有効にできるかは AWS アカウントの都合などもあります。 プロジェクトのポリシーと合わせてどういった形で利用するかは検討してください。 インストール & 初期設定 現在の Amazon Qの CLI は Linux 環境にしか存在していないので注意が必要です。 Windows の場合は以下のような手段で環境を構築するのが良いでしょう。 WSLを導入する DevContainerを導入してその上で利用する なお、 Amazon Qの CLI の更新は頻繁でaptの リポジトリ の整備がなされていないので定期的に入れ直しが発生するかもしれません。下に示すインストールコマンドを再度実施するなどして環境を随時最新になるようにしてください。 公式手順に従い CLI を導入 自分は以下のような手順で導入しています。 cd /tmp wget https://desktop-release.q.us-east-1.amazonaws.com/latest/amazon-q.deb sudo apt-get install -f sudo dpkg -i amazon-q.deb rm amazon-q.deb Amazon Qを起動 インストールが完了したらまずはログインします。 ターミナルで以下のコマンドを実行してください。 q login すると ? Select login method › ❯ Use for Free with Builder ID Use with Pro license 上記のような選択肢が出るので、「Use with Pro license」を選んでアカウントの情報を順番に入力していってください。最終的にブラウザが起動して認証を行うことになります。 これで Amazon Qを起動する準備が整いました。 以下のコマンドで起動できるはずです。 q 起動すると以下のような画面が表示されるはずです。 基本的な使い方 Amazon Qが起動したらあとは好きなように指示を出せば Amazon Qがコードを書いたり様々なタスクを実行してくれます。 例えば「Next.jsで hello world アプリを作って」みたいな大雑把な指示でもある程度動作してくれます。 このままでも、十分便利なのですが、この状態ではまだ Amazon Qの使い方としてはもったいないです。 以降ではこれを改善する細かいテクニックなどを紹介します。 Amazon Qのより効率的な利用方法 ツールの実行を自動承認する Amazon Qが外部のプログラムを実行する場合、都度承認を求めてきます。 いちいち応答するのは面倒なうえ開発速度が落ちてしまいます。なので、自動承認してしまうことにします。 /tools trust all これを許可するために、Dev Containerの環境を構築して実行するのがおすすめです。 Amazon Qは極端な話ですが rm -rf / だろうがなんでも実行してしまいます。実際に Amazon Qにrebootコマンドを実行されてしまったという話を聞いたことがあります。他にもaptで何かをインストールされたり、 curl https://.../ | sh ... のような スクリプト を実行されたりします。 プロンプトでこれらのコマンドの実行を禁止するなどして制御はある程度出来ますが完全ではありません。この自動承認を許可するためにコンテナのような分離された独自の環境を用意してその上で実行するべきです。 コンテキストを常に意識する Amazon Qに限らず生成AIのモデルにはコンテキストという概念があります。 これは現在のモデルがどの程度の文書を保持しているかといったものになります。 人間の短期記憶に近い概念ですね。 この容量は現在のAIではそれほど巨大ではありません。例えばプロジェクトの全 ソースコード を収めるといったことは通常できません。ドキュメントについても同様です。このためこのコンテキストにいかに情報を詰め込んでいくかということが生成AIによるコーディングでは重要になります。 また、このコンテキストに情報を詰め込みすぎても上手く行きません。コンテキストが不足してくると生成AIは途端に制御が効かなくなり、同じことを繰り返し続けたり、全然関係ない作業を始めたり、誤魔化そうとしたりと様々なことを始めるようになります。 つまり、コンテキストには今実際に作業を行っている内容に関係がある必要最小限の内容となっている状態が最良の状態ということです。そうなるようにプロンプトや指示の仕方を工夫していく必要があります。 また、このコンテキストを制御するコマンドがいくつかあるので上手く使っていきたいです。 特に、 /clear や /compact といったコマンドは Amazon Q自体が勝手に実行したりします。 /clear は現在のコンテキストをまっさらにするコマンドです。 /compact は現在のコンテキストを圧縮(サマライズ)して格納し直すコマンドです。 このコマンドのうち /clear は非常に多用するコマンドになります。 逆に /compact コマンドは Amazon Qが自分で勝手に実行することがあります。これはコンテキスト量を自分で把握していて不足してきたら実行するためです。この状態になってしまったらもはや適切な動作は望めません。現在の作業を中断するなりして /clear を実施し、与えるコンテキストや指示内容などから見直しを実施すべきです。 理想的には何か指示を出して結果を受け取ったら /clear を実行することが望ましいです。 システムプロ ンプト(AmazonQ.mdなど)について AmazonQは動作する際に、いくつかのファイルを自動的に読み込むようになっています。 AmazonQ.md .amazonq/rules/*.md この中に色々記述することで動作をカスタマイズすることが出来ます。 なお、これらのファイルのベストな書き方はまだ世の中にも答えがない状態だと思います。 さらに使っているツールによっても違うと思います。 Amazon Qをメインで使っている自分とClaude Codeを使っている人では大幅に内容が違うということも十分あると思います。 ここでは、自分が Amazon Qを使っていて、こう設定したほうが良いなと考えていることを紹介します。 また、重要なことですがこれらのファイルの管理も「 Amazon Qに書かせる、整理させる」のです。 「〇〇 (ファイル名)にこのようなことを追加して必ず守るようにして」などと指示をする 定期的に「〇〇ファイルが大きくなったので整理して簡潔にして」などと指示をする このような指示を行ってプロジェクトや自分用のプロンプトを育てていくと良いでしょう。 AmazonQ向けの工夫 ここでは、 Amazon Qを使っていて気がついた Amazon Qを使う上で注意、工夫が必要なことについて紹介します。 ドキュメントの書き方/書かせ方 開発ドキュメントなども含めてAIに書かせたいと思うのは自然なことだと思います。 ただし、 Amazon Qは以下のような文書を書く癖があります。 とにかくコードを使って説明したがる コードの話をしていないのに具体的なコードを使って文書を書いてしまう まだ説明していないことを勝手に補完してしまい膨大な分量の文書を書いてしまう これらの動作を抑制するためのプロンプトをAmazonQ.mdなどには記載しておくべきです。 指示した以外の内容はドキュメントに記載するな コードを使った説明は指示しなかった場合以外はドキュメントに記載するな などと指示しておくことで抑制できます。具体的なフォーマットを指示しておくと一層効果的です。 特にコードを使った説明や不要な文書はコンテキストを消費するだけで無駄なので常に避けるべきです。 Amazon Qに実行させるコマンドについての注意点 ログを大量に生成してしまうコマンド コンテキストに関連することもあり、ログの出力には気をつける必要があります。 例えば、テストで スタックトレース を出力するなど膨大なログが出るような場合はそれだけでコンテキストを消費します。このログの出力については自分が試していても顕著に効果がありました。実装の最初のうちは、テストで何も考えずに普段通りログ出力が多い形でテストを実施していたところ、簡単にコンテキストが枯渇し Amazon Qが無限ループに突入しました。そこで、テストでは極力不要なログを出さないように実装させることでテストもちゃんと実施できるようになりました。 ユーザの入力待ちになるコマンド また、テストやサーバ起動のコマンドについても注意が必要です。 Amazon Q は簡単に入力待ちになってしまうコマンドを実行します。 例えば、 npm run start コマンドなどは起動後は Ctrl+C の入力待ちになっている場合がほとんどだと思います。 Amazon Qがこれを実行してしまうと完全に動作が停止します。これは困るので、AmazonQ.mdなどでプロジェクトで実行するコマンドは明示するようにし、上記のコマンドの場合ではnohupを使ったものを使うように設定しておくと上手くいきます。 理想的にはプロジェクトに関係があるコマンドは全てドキュメントにまとまっていて場当たり的なコマンドはAIには実行させない形になっていると良いです。 とはいえ、実際には Amazon Qが勝手に色々実行したりすることが多いです。その場合は落ち着いてAIに代わって自分が追加の入力をしてあげる、もしくはCtrl+Cを押して追加の指示を出し、「そのコマンドを実行するならnohupをつけて実行してください」などと依頼して回避することができます。 なお、 Amazon Qはたまに npm run start& などと実行して回避しようとしたりするのですが、これは正常に動作しないプロセスが生成されるようです。なのでnohupをつけたうえでバックグラウンドで実行するように指定する必要があるようです。 Amazon Qの得意、苦手なこと ここでは、 Amazon Qが得意なこと、苦手なことについて紹介します。 得意なこと Amazon Qは基本的に愚直に作業を行ってくれるので、そういった仕事は得意です。 地道に行うことが求められる作業 複雑でなく量が膨大となるような作業はとても得意です。 このプロジェクトの特定の ディレクト リの下にある関数に〇〇というクラスを引数として与えるようにして Nextのフロントエンド部分を切り出して独立したReactのプロジェクトにしてほしい など人間がやると苦痛に感じる作業でも淡々とこなしてくれます。Vueに変更するのは単純作業ではないですが、頑張ってやりきってくれます。 テストの生成 テスト作成、モック作成 のような作業は得意です もちろん、ちゃんとテストできているかは確認する必要があります。例えば、coverageを測定することで一定の安心感を得ることはできると思います。 計画を立てること 作業内容について Amazon Qと相談し、結果を作業手順書や計画書としてまとめるようにするとそれなりに整った計画書にしてくれます。 さらにそれをTODOリストの作成と指示すると 進捗管理 も出来て便利です。 Amazon Qの苦手なこと Amazon Qを使っていて苦手だなと感じる作業を簡単にまとめておきます 課題 症状 対策 インフラ構築の作業が苦手 DockerfileやTerraformなどを書かせると内容が古かったり、そもそも動かないものが生成される 生成後に人間がレビュー シェルスクリプト が下手 全く使えない シェルスクリプト を生成する。 書かせない、もしくは他のツールの利用を検討する 開発環境整備が苦手 環境変数 をうまく設定して起動するようなものが苦手。 レビューをちゃんとやる、もしくは人が構築する。 PORTという 環境変数 を作っているのに、APP_PORTという 環境変数 を別に作ったりする。 不要コードを残してしまう リファクタ後も極力古いコードを残そうとする 「使わないコードを削除せよ」と明確に指示して削除する。それでも残そうとするので人間がたまにチェックする。 どうも、インフラが関わってくる操作が顕著に苦手なようです。 シェルスクリプト が苦手なのは意外でした。例えばChatGPTなどは シェルスクリプト をとても綺麗にかいてくれる印象があったので Amazon Qもそうなのだと期待していたのですが現状だと難しいようです。 Amazon Qが快適に作業を行えるように さらに Amazon Qが作業しやすいように、 Amazon Qの作業結果を受け入れやすいように環境の整備を行っていくことも重要です。 ここではそういった作業の例をいくつか紹介します。 ガードレールの整備を行う git pre-commitでLint／フォーマット／静的解析を行う 作業が完了したらdiffを確認して問題がないかなどのチェックを行う これもAIにやってもらうのが理想 別ウィンドウで Amazon Qを動作させ確認させるなどで実現 ファイルの整理 不要なドキュメント、不要なファイルは極力排除する ファイルが探しやすい ディレクト リ構造にしておく 事前準備などの苦手なことは人間が引き受ける Dockerfile、Terraform などのインフラに関するコードは人間が必ずレビューし動作確認する 場合によっては人間が全部書いたほうが良いこともある 開発環境の初期設定は可能な限り人間があらかじめ実施 CI/CD環境、デプロイ スクリプト なども人間がやったほうが早い 自分がとりあえず採用したワークフローと得られた生産性 自分が現在使っている作業の流れは以下のような流れになります。 # ステップ 具体的な操作 1 着手前 要件箇条書きを渡して「作業計画書」「 ADR 」を Q に作成させる 2 ToDoリストの作成 作業計画を元にToDoリストの作成を行ってもらう 3 コード生成 ToDoリストに従ってコード生成を進めていく。TDDで極力すすめてもらう 4 タスク管理 ToDo リストを Q に更新させる、ToDoリストは定期的に整理を指示する 5 コンテキスト整理 1つの作業完了、もしくはやり取りが増えたら /clear 。 このフローで、概ね1週間で1-2万行くらいのコード生成ができました。もちろん常にこの結果が得られるとは限らないと思います。あくまで参考情報です。 さらに後半は読まないといけないコードや文書量が増え消費するコンテキストの量が増えていくため、生成速度はだんだん遅くなっていくような状況になりました。 この状態からさらに生産性を上げていくには、例えば Amazon Qを複数起動させることで増やしていくこともできるでしょうが、レビューしたり、人間のほうが ボトルネック になっていきそうですね。 スケールの限界と分割戦略 自分が Amazon Qを使っていて、これ以上の規模になると一気に生産性が落ちたり、プロジェクトの進行が著しく遅くなったと感じた基準について紹介します。 ソースコード の行数の上限は約2万行 程度だろうと感じました。可能であれば1万行に達する前に対策を検討するのが良さそうです。対策としてはプロジェクトを分割、または ディレクト リ単位で Amazon Qのプロセスを分けるなどの対策が良さそうでした。ただし、使う言語などによっては ディレクト リ分割では分割として認識が弱いようです。例えば、Nodeの場合だと ディレクト リよりもパッケージ分割を行うほうが上手く行くようでした。また、分割後は インターフェイス 仕様書のようなものを整備し、 ソースコード の参照を減らすことでコンテキストの消費を防ぐことも重要でした。 また、個別のファイルについても大きくなりすぎない方が上手く行くようです。例えば、ファイルは最大でも500行程度で分割したほうが上手く編集してくれるようでした。 MCP サーバについて 便利なので導入すると良いかもしれないです。ただし、自分はあまりまだたくさんは導入していないです。 playwrightの MCP サーバは便利でした。これを頻繁に起動すると時間がかかるようになるので要検討だと思います。 Amazon Qで MCP を使うには ~/.aws/amazonq/mcp.json に設定を追記すれば利用できます。 例えば、以下のように記述することでplaywrightの MCP サーバを利用できるようになります。 { " mcpServers ": { " playwright ": { " command ": " npx ", " args ": [ " @playwright/mcp@latest " ] } } } Amazon Qを使っていて遭遇する問題 Amazon Qを使っているとエラーが表示されることがある 稀にエラーが出るようですが、再起動するしかないようです モデルを選び直すように指示される /modelを入力して別モデルを使う Amazon Qの入門としておすすめすること これから試す人は例えば以下のようなことをやってみると Amazon Qの使い方が何となく分かるのではないでしょうか AmazonQ.md に “プロジェクトの開発ルール” の雛形を作成させる /tools trust-all を実施しても大丈夫な環境(devcontainerなど)を立ち上げ、 Hello World アプリを 1 日で作る 生成されたテスト・ドキュメントの質と開発速度を確認し、チームのベストプ ラク ティスを固める まとめ Amazon Q Developerはとても良いツールなので是非皆さんも使ってみてください。 余談 AWS がkiroというAIを活用している IDE を発表しましたね。 これが採用しているワークフローが自分が構築したワークフローとかなり似ていて 偶然ですが、 Amazon Q向けの使い方を自分は意図せずしていたようです。 執筆： @yamashita.tsuyoshi レビュー： @mizuno.kazuhiro （ Shodo で執筆されました ）

はじめに はじめまして。 電通 総研セキュアソリューション 第1ビジネス統括 デジタルビジネス推進事業部4年目の城田 陽生です。 2025 Japan AWS Jr. Champions に選出された当社グループのメンバーにインタビューを行い、これまでの取り組みや今後の抱負などについて語ってもらう企画を実施しています。 今回のインタビュー対象は 電通 総研の佐藤 悠(Sato Yu)さんです。 2025 Japan AWS Jr. Championsとは AWS Partner Network (APN) 参加企業に所属し、現在社会人歴 1～3 年目で突出した AWS 活動実績がある若手エンジニアを「Japan AWS Jr. Champions」として表彰します。これは、 AWS を積極的に学び、自らアクションを起こし、周囲に影響を与えている APN 若手エンジニアを選出しコミュニティを形成する、日本独自の表彰プログラムです。 [引用] 2025 Japan AWS Jr. Champions クライテリアと応募方法のお知らせ 自己紹介 ――現在の所属と業務の内容を教えて下さい。 所属は エンタープライズ 第一本部 テク ノロ ジー ビジネス2部 3Gです。普段は AWS や Kubernetes に関する業務を中心にインフラエンジニアとして働いています。 ―― AWS に関わるようになったきっかけは？ AWS NewGradsという新人向けの AWS 講義があってここで2025 Japan AWS Jr.Championsについて知りました。実際に AWS を使用し始めたのは1年目の10月に配属され、 AWS 領域の業務に アサイ ンされたタイミングです。業務を行うにあたって知識を習得したかったのでCLFを受験しましたが、この対策の過程で様々なサービスがあることを知り AWS 自体に興味を持つようになりました。 ――学習のモチベーションは何ですか？ 資格を持っている先輩が部署にいたのでよい刺激をもらいました。先輩は1年目でProfessional資格まで取得していたので、SAAまでで終わらずより難しい試験に挑戦しようというモチベーションになっていました。さらに学習意欲の高い同期が同じ事業部にいたのも、競争する環境になり良かったです。試験合格の度に報告しあっていて、負けず嫌いな私は常に緊張感とスピード感をもって勉強していました。 ―― AWS のキャッチアップ方法をおしえてください。 まずは資格ベースで学習し、 AWS の全体感をつかむようにしていました。資格の勉強は参考書で実施していましたが、興味があるサービスに関しては AWS Hands-on for Beginnersという AWS が出している初心者向けのハンズオント レーニン グを実施し、より細かい設定や具体的な ユースケース を学びました。このハンズオンの中でも スケーラブルウェブサイト構築編 や サーバーレスアーキテクチャで翻訳 Web API を構築する を学び初めに触ったのが良い経験になりました。 クラウド を利用するにあたりスケーラブルであることを実感できる1つ目の講座と、サーバーレスリソースで簡単に API が実装できる手軽さ・複数のリソース間でロールを用いた許可を理解できる2つ目の講座が面白かったので本当におすすめです。 2025 Japan AWS Jr. Championsについて ――2025 Japan AWS Jr. Championsを目指した理由を教えてください SAPを取得したときにこの表彰制度を思い出し、資格上のクライテリアを満たしたので目指すことにしました。 ――選出に向けてはどのようなことを取り組みましたか？ 業務面ではEKSを使用した内容を実施しました。概念的な内容が多く難易度が高い内容ですが、キャッチアップしながらエコシステムのバージョンアップ等を行ったのが評価されたと思います。後は資格取得支援の内容をまとめたものや、最近興味のある領域で AWS から提供されているAIサービスを触って解説するブログを執筆しました。過去の選出者から話を聞いたときには、社外への発信活動が評価されていそうだという話を聞いていたのが理由です。これに加えて、社内向けにサーバーレスの勉強会を開いたり、 AWS のト レーニン グに参加してこれを自部署に共有したりして社内向けにも積極的に活動していました。 ――今後は2025 Japan AWS Jr. Championsとして1年間どのような活動をしたいですか？ 社内でもこの表彰制度を目指したいという人の声を聞くようになったので、今までの活動の知見を生かして後に続く人を出したいです。 最後に AWS Jr. Championsを目指している方、若手で早くから多くの AWS の資格を取得を目指している方は非常に参考になったのではないでしょうか？？ 皆さんもぜひ挑戦してみてください！ 最後まで読んでいただきましてありがとうございました！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @shirota.akio レビュー： @akutsu.masahiro （ Shodo で執筆されました ）

はじめに はじめまして。 エンタープライズ 第1本部2年目の佐藤悠です。 2025 Japan AWS Jr. Champions に選出された当社グループのメンバーにインタビューを行い、これまでの取り組みや今後の抱負などについて語ってもらう企画を実施しています。 今回のインタビュー対象は、 電通 総研セキュアソリューションの城田 陽生(Shirota Akio)さんです。 2025 Japan AWS Jr. Championsとは AWS Partner Network (APN) 参加企業に所属し、現在社会人歴 1～3 年目で突出した AWS 活動実績がある若手エンジニアを「Japan AWS Jr. Champions」として表彰します。これは、 AWS を積極的に学び、自らアクションを起こし、周囲に影響を与えている APN 若手エンジニアを選出しコミュニティを形成する、日本独自の表彰プログラムです。 [引用] 2025 Japan AWS Jr. Champions クライテリアと応募方法のお知らせ 自己紹介 ――現在の所属と業務の内容を教えてください。 所属は第1ビジネス統括 デジタルビジネス推進事業部 クラウド エンジニアリング部です。部署名の通り、 クラウド （特に AWS ）を用いたインフラ部分を担当し、構築運用保守を行っています。 ――情報系のバックグラウンドはありましたか？ 理系ではありましたが、材料工学出身なので情報を専攻はしていないです。IT業界を志した理由は、いろいろありますがPC作業が好きだったことが1つに挙げられます。 ―― AWS を始めたきっかけは？ 会社に入ったタイミングで業務で触ったのがきっかけです。 クラウド に入門したのはAzureでしたが、 AWS の学習環境が自分にあっており AWS の方が得意になりました。 ――かなり資格も持っていますよね？ 2週間~半月に1個のペースで取得していたら、全ての資格を取り切れました。 ――すごいですね！そのモチベーションはどこから来るのでしょうか？ AWS が視界に入る瞬間が多かったのが理由ですね。私はゲームが趣味なのですが、 AWS の障害時に軒並みサービスが停止をしたときに、逆に様々な環境で使われているんだと実感しました。ここまで様々なところで使われていると、それだけ世の中への影響力がある仕事ができると感じています。 ――やはりシェアの大きさを実感するとやる気になりますよね！ちなみに AWS で好きなサービスはありますか？ VPC ですね。全ての基本は VPC にあります。 2025 Japan AWS Jr. Championsについて ――2025 Japan AWS Jr. Championsを目指した理由を教えてください この表彰制度を知ったのは、CCoEの活動を通してでした。 ――CCOEとは？ Cloud Center of Excellenceの略で、 クラウド 活用を推進するために組織横断的に活動するチームです。面白そうだったので進んで参画して資格支援を行いました。そこでJapan AWS Jr. Championsのことを知り、年次の制限もあり今しかできないこと、そしてまだ誰もやったことがないことをやりたいと思ったのがきっかけに目指すことにしました。また、社外イベント参加した際に前年度のJr.Championsと話したのも良い刺激になりました。 ――社内でも初めての選出者ですからね！選出に向けてはどのようなことを取り組んできたんでしょうか？ CCOEの取り組みが中心ですね。具体的には資格取得の支援のために、報奨金の設定や自ら資格を取得することで体験記を出すような活動を行っていました。初学者の人はモチベーションの管理や取得方法に悩むこともあるのでそのような環境整備を積極的に行ってきました。これは社内の同期で共に頑張れる三浦がいたのも継続する力になっています。 ――今年は三浦さん（ 電通 総研セキュアソリューション 三浦杏之介）と2人で選出ですからね！他にはどのようなことをしましたか？ 社内LTの開催や AWS に関する外部のイベントに参加して得た知見を内部向けにレポートを作成するような活動の他、実践道場のとりまとめのような窓口業務までも担当していました。自分がCCOEの活動を牽引する気持ちで頑張って来ました。 ――今後は2025 Japan AWS Jr. Championsとして1年間どのような活動をしたいですか？ まずは、自分も含めてJr.champions全員が参加できるようなコミュニティを形成したいですね。今は既に行動力のある人がイベントを企画して推進していますが、そこに乗っかり切れない人がいないように声掛けをして人のつながりでイベントを開催できればと考えています。アウトプットは今までできていない部分もあったのでブログを作成することやLTに参加することなど、初歩的な部分からはじめていきたいです。個人的には、今までに触ったことのないサービスを触ってみて、入門のハードルを下げるところに焦点を合わせた発信ができることが理想です。最後の大きな目標として、2025 Japan AWS Jr. Championsを終えた後に会社にメリットを持ち帰り、先駆者として活躍することで私に続く人が増えることを目指しています！ 最後に AWS Jr. Championsを目指している方、若手で早くから多くの AWS の資格を取得を目指している方は非常に参考になったのではないでしょうか？？ 皆さんもぜひ挑戦してみてください！ 最後まで読んでいただきましてありがとうございました！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @sato.yu レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

こんにちは。 電通 総研クロス イノベーション 本部3年目の宮崎博寿です。 現在、 2025 Japan AWS Jr. Champions に選出された当社グループのメンバーにインタビューを行い、これまでの取り組みや今後の抱負などについて語ってもらう企画を実施しています。 今回、私がインタビューさせていただいた方は、 電通 総研セキュアソリューションの三浦 杏之介さんです。 自己紹介 ――現在の所属と業務の内容を教えて下さい！ ICTサービス事業部 ICT3部に所属し、 クラウド セキュリティ領域を中心に業務を行っています。具体的には AWS GuardDuty や サードパーティ 製セキュリティツールの運用・検証・提案・外販を担当しつつ、EC2 環境のコンテナ／サーバーレス移行支援や DGCP（社内基盤）の技術支援にも携わっています。 ――情報系のバックグラウンドはありましたか？ 大学では情報処理を学んでおり、 自然言語処理 を研究していました。ある程度のIT知識やプログラミング経験はあったものの、 クラウド に関しては無知であり、社会人になってから AWS を知りました。 ―― AWS を始めたきっかけは？ 「セキュリティを極めるなら、まずはその土台となる基盤を深く理解すべきだ」と考えたことが出発点です。まずは机上からと AWS の資格を取得することから始めました。 2025 Japan AWS Jr. Championsについて ――2025 Japan AWS Jr. Championsを目指した理由を教えてください！ AWS イベントである実践提案道場でこの制度を知り、「社外コミュニティで切磋琢磨しながら視野を広げたい」と感じたのがきっかけです。若手のうちから外に飛び込むことで、自分の成長スピードをさらに加速できると考えました。また、同じような仲間から刺激を受けモチベーションにもつながると考えたからです。 ――選出に向けてはどのようなことを取り組んできたんでしょうか？ はい、いちばん力を入れたのはアウトプットです。まず、社内外でブログを継続的に執筆して学びを共有しました。 加えて、コミュニティ活動として社内の LT 会や、外部イベントにも積極的に登壇してナレッジを発信しました。　　　　　　 さらに資格面でも、社内で初めて AWS 認定 12 冠を達成することができました。　　　　　　　　　　　　　　　　　 啓蒙活動としては、社内 Tech 勉強会を企画・運営しつつ、新サービスの検証レポートも定期的に配信して、組織全体の技術キャッチアップを後押ししてきました。 ――12冠！すごいですね、そのモチベーションはどこから来るのでしょうか？ 社内に誰もいなかったことと、モチベーションを与えてくれる存在がいたことの2点です。 4つ目を取ったあたりから「全部取れるかも」と思うようになり、それと同時期に社内では今まで誰も成し遂げていないことを知りました。無名の若手が12冠したらウケるだろうなーというのをモチベーションに、ひたすら勉強していました。「2025 Japan All AWS Certifications Engineers」に選出される期限が2025年3月末までであり、それに間に合わせたいという気持ちもありました。結果的には新卒時代に取得したCLFを除いて、11個を約1年で合格することができました。 また、私の上司が外部イベント参加や自己研鑽を奨励してくれるスタンスの人で、資格取得を常に応援してくれていました。入社してから今日までずっとお世話になっている人なので、この人のためにもやってやろうと思っていました。 ―― AWS All Certifications Engineers を目指している方にコツやおすすめの勉強方法あれば教えてください！ 12個全部取るのは何かしら強烈な意思がないと不可能です。私は近所のファミレスで勉強することが多かったのですが、「マヨコーンピザが食べられる！」というのをモチベーションにしていました。動機はなんでもいいのでとにかく机に向かうきっかけを作るのがおすすめです。 あとは勢いも大事です。なるべく期間を空けずに連続して受験することを推奨します。 AWS の試験はアーキテクトやセキュリティ、 機械学習 など複数の分野がありますが、国語と数学をやらされているわけではなく、 幾何学 と 微分 積分 をやっているようなものです。つまり応用が利きます。ひとつ前の試験で覚えたサービスや機能は次の試験でも登場します。短期集中で一気に数を稼ぐといいと思います。 ――今後は2025 Japan AWS Jr. Championsとして1年間どのような活動をしたいですか？ まずは 社内・グループ全体を巻き込むイベントを主催 したいと考えています。 具体的には GameDay や Builder Cards といったハンズオン形式のワークショップを企画し、“遊びながら学ぶ”体験を提供します。 これにより、業務の合間でも気軽に クラウド 技術へ触れられる場をつくり、組織全体の技術力と学習意欲を底上げしたいと思っています。 次に、私は “話せるエンジニア” を目指しています。大型カンファレンスやコミュニティイベントで積極的に登壇し、自分の知見や失敗談をオープンに共有することで、参加者との相互学習を促進したいです。 また、コミュニティ運営にも携わり、若手エンジニアがアウトプットしやすい環境を整えることで、自分自身のプレゼンスも高めていきます。 最終的には 社内初の Top Engineer に選出されること を目標にしています。 そのために、技術力の研鑽はもちろん、社内外での影響力やリーダーシップを磨き、メンバーが挑戦しやすいカルチャーづくりに貢献したいと考えています。こうした一連の取り組みを通じて、2025 Japan AWS Jr. Champions の名に恥じない成果を残したいです。 最後に AWS Jr. Championsを目指している方、若手で早くから多くの AWS の資格を取得を目指している方は非常に参考になったのではないでしょうか？？ 皆さんもぜひ挑戦してみてください！ 最後まで読んでいただきましてありがとうございました！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @miyazaki.hirotoshi レビュー： @kinjo.ryuki （ Shodo で執筆されました ）

はじめに はじめまして。 電通 総研セキュアソリューション ICTサービス事業部の三浦杏之介です。 2025 Japan AWS Jr. Champions に選出された当社グループのメンバーにインタビューを行い、これまでの取り組みや今後の抱負などについて語ってもらう企画を実施しています。 今回のインタビュー対象は、 電通 総研の宮崎 博寿さんです。 2025 Japan AWS Jr. Championsとは AWS Partner Network (APN) 参加企業に所属し、現在社会人歴 1～3 年目で突出した AWS 活動実績がある若手エンジニアを「Japan AWS Jr. Champions」として表彰します。これは、 AWS を積極的に学び、自らアクションを起こし、周囲に影響を与えている APN 若手エンジニアを選出しコミュニティを形成する、日本独自の表彰プログラムです。 [引用] 2025 Japan AWS Jr. Champions クライテリアと応募方法のお知らせ 自己紹介 ――宮崎さんの自己紹介をお願いします。 宮崎 博寿（みやざき　ひろとし）です。2023年入社の3年目で、クロス イノベーション 本部 クラウド イノベーション センターに所属しています。 ――好きな AWS サービスは？ CloudTrailやTrustedAdvisorが好きで、アカウント全体を監視・管理できるサービスがお気に入りです。 ――現在の業務を教えてください。 大きく分けて2つあります。 1つ目はPOSITIVEのインフラ担当として AWS やOCIを中心に触っており、導入・構築・運用に関わっています。 AWS ではEC2やRDSを中心としたインフラ構成を触っており、直近ではこれらをCloudFormtionでIaC化する業務をしていました。 2つ目は社内の研究開発（社内プロジェクト的なもの）にてメンバーとして調査や技術の検証を行っています。 直近では ITIL に基づいた SaaS サービスやオブザーバビリティ領域の SaaS サービスの調査を行いました。 ――社内の最前線で クラウド を推進する活動をされているんですね。 新しい技術に触れられる環境で、幅広い技術やサービスに触れることができ個人的には楽しく充実しています。 ―― AWS に興味を持ったきっかけを教えてください。 もともと文系出身で経済を学んでおり、ITとは無縁の学生生活でした。そんな中で 電通 総研に入社し、新人研修で「 クラウド 」という技術を知りました。 クラウド は現在進行形で需要が拡大している事業領域であり、これを扱えることが今後のキャリアを広げるで必須のスキルであると考え、意欲的に取り組むことにしました。 ――文系出身でここまでの成長を遂げ成果を挙げていることは、特に若手の文系出身社員にとって希望ですね。 文系理系はそこまで大きな影響はなく、入社してからどれだけモチベーション高く学習できるかが大事だと考えています。若手社員の方は自分が興味を持てる技術をとことん勉強してみるのがいいと思います。 2025 Japan AWS Jr. Championsについて ――次はJr. Championsについて聞かせてください。まずは選出を目指した理由を教えてください。 上司からJr.Championという制度があると聞いて存在を知りました。キーワードで検索すると多くの記事が転がっているので目を通してみると、若手が意欲的に活動して自身の技術力やリーダーシップを鍛えることができる環境であるそうです。 もとからレベルの高い環境に属してみたいという希望があり、3年目までの若手限定という制限があり、2度とないチャンスだと思ったので飛び込んでみることにしました。 ――レベルの高い環境に期待しているとのことですが、初回キックオフを終えた今、どのような印象を受けていますか？ 期待通り、みなさんオーナーシップをもって行動されています。Jr. Champions専用のSlackチャネルがあるのですが、さっそく活発に動いていて、早い人はイベントの開催などを行っていてすごいなと感じています。我々も 電通 総研グループとして負けていられないです。 ――Jr. Championsに選出されるために、宮崎さんが取り組んできたことを教えてください。 目の前の業務で AWS に関する業務を様々携わらせていただいており、そこが一番大きいですが、社内で AWS に関する啓蒙活動やアウトプットする機会があり業務外での取り組みも行いました。 具体的な業務外の活動としては社内の資格取得の勉強方法を共有したり、 電通 総研テックブログで執筆活動をしたり、社内の クラウド SOC勉強会でお話する機会をいただきGameayについて共有したことです。 所属部署的に クラウド に関する活動を、特に無理をすることなく自然とやりやすい土壌という面も大きいです。 ――Jr. Championsの任期であるこの1年の展望を教えてください。 まずは爆発的に市場が大きくなっている生成AIをキャッチアップしたいです。 AWS でも Amazon QやBedrockが生成AIサービスとして該当しますが、これらの最新機能はアンテナの感度を高めて常に触れるようにし、インプットとアウトプットを繰り返します。Jr. Championsでも生成AI系のイベントは開催されていくと思うので、積極的に参加したいです。 また、Jr. Championsの先にはTop EnginnerやAmbassadorという道が待っています。社内および社外での存在感を高める一年間として、これらの目標に近づきたいです。Ambassadorになるためにはビジネスと技術面の両軸での活躍が必要だと思うので、2軸で強みを持っている存在の証明であるAmbassadorになることを、今後も AWS に関して頑張るモチベーションの1つにしています。 ――最後に一言、エンジニアとしての抱負をお願いします。 電通 総研の中で、「 AWS といえば宮崎」と呼ばれる存在になりたいです。この1年で圧倒的に経験を積んで強いエンジニアになります。 最後に AWS Jr. Championsを目指している方、若手で早くから多くの AWS の資格を取得を目指している方は非常に参考になったのではないでしょうか？？ 皆さんもぜひ挑戦してみてください！ 最後まで読んでいただきましてありがとうございました！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @miura.kyonosuke レビュー： @iwasaka.emari （ Shodo で執筆されました ）

こんにちは、 電通 総研 コーポレート本部 サイバーセキュリティ推進部の櫻井です。 本記事ではCompTIA SecurityX認定に関する紹介をします。 なお、本記事でご紹介する資格の情報は2025年5月時点のものとなります。 CompTIA SecurityX認定とは？ CompTIAはIT業界内で作成された各業務の実務能力基準の認定活動などを行っているIT業界団体であり、同様の団体にはISC2(International Information System Security Certification Consortium)やISACA(Information Systems Audit and Control Association)が挙げられます。 また、CompTIA SecurityXはCompTIAのサイバーセキュリティ分野の資格群では最上位(EXPERT)にマップされています（※1）。 Comptia IT Certification Roadmapより出典 想定される受験者としてサイバーセキュリティ分野における高位の実務者を想定していますが、ガバナンス、リスク、 コンプライアンス の要件と法律を意識した設計での知識も要求されます（※2）。また、米国 国防総省 指令 8140.03M で定義されている DCWF（The DoD Cyber Workforce Framework）内のワークロールにも マッピング されています（※3）。 あとから思いましたが、なんかすごそうな資格です。 ※1 Comptia IT Certification Roadmap ※2 Comptia 公式サイト(日本語) ※3 CompTIAとDoDM8140.03：サイバーセキュリティ分類標準の遵守 以降、CompTIA SecurityXを本試験と表記しますのでご了承ください。 受験に至った経緯 筆者は前職までオンプレ、 クラウド を問わずシステムの設計/構築/運用を行ってきました。 電通 総研に中途入社し、現職（サイバーセキュリティ推進部）の業務ではシステムのリスク評価や社内のガバナンス、リスク評価、技術的セキュリティレビューに関わる必要があり、包括的なセキュリティ フレームワーク の知識を習得することが必要と考えている最中に本試験の存在を知りました。 本試験の他に横並びで受験を検討していたものとしては、ISC2が主催するCCSP（Certified Cloud Security Professional ※4）や CISSP (Certified Information Systems Security Professional ※5)がありましたが、前段となるSecurity+や CySA+が存在し、ステップアップがふみやすい点を考慮し、本試験を含むCompTIAの認定試験を選択しました。 また、本試験は2024年12月に新しく配信が開始されたCAS-005と以前から存在するCASP+(旧CompTIA Advanced Security Practitioner+)から名称が置き換えられたCAS-004の２種類の試験が受験可能が存在しますが、今回は予約時点で日本語試験対応済みであったCAS-004を受験しています。 ※4 CCSP®とは ※5 CISSP®とは 試験概要 CompTIA公式の紹介から要点を紹介します。（※6） テスト形式：CBT（ピアソンVUE予約） テストセンター受験、オンライン受験（※7） 問題数：最大90問 出題形式：単一/複数選択、パフォーマンスベーステスト 試験時間：165分 その他 退出（とりわけ途中離席）が可能かはテストセンターに事前に確認した方がよさそうです。 ※6 CompTIA CASP+ 試験情報 ※7 CompTIA オンライン試験実施概要 単一/複数選択 複数の選択肢から１つの選択肢を選ぶ一般的な選択問題です。 パフォーマンスベーステスト 一般的な表現ではシミュレーション問題となります。正解の選択肢が複数存在するケースについては全て選択する必要がありますのでその点を注意してください。また、事前にCompTIA公式のサンプル問題を確認しましょう。（※8） ※8 CompTIA パフォーマンスベーステスト サンプル問題 試験に出題される領域 一言でいうと「幅広い」という表現になり、本試験では主に技術用語に関して膨大な知識を要求されます。 セキュリティなら全部という表現が正しいですが、技術の階層に関してはオンプレ or クラウド 、アプリケーション or インフラという二者択一ではなくセキュリティすべての領域が対象です。 様々な試験を受けてきた筆者ですが、ここまで広範囲の領域を問われる試験は経験がなくひたすら自力を要求されます。 設計/開発のみの経験しかない場合はインシデント対応や リスクアセスメント のケース問題で悩むことはあるかと思いますが、必要とする知識を備えていれば後述の問題集を元に対応することは可能だと筆者は考えています。 注意点 本試験には一般的なITインフラから外れる内容として産業向けインフラ分野が含まれています。筆者もこの試験を受ける前まで触れたことがなく、大部分の方は初めて接することになると思われますので、用語リストで確認を行いましょう。 分野配分 本試験の分野としては以下の4分野の配分となっています（※9）。海外の法律に関する問題を含め、普段あまり触れることのない領域の問題も出題されますので、後述の略語リストで確認を行いましょう。 セキュリティ アーキテクチャ 　29% セキュリティオペレーション　30% セキュリティエンジニアリングと暗号化技術　26% ガバナンス、リスク、 コンプライアンス 　15% ※9 CompTIA CASP+ 試験情報 予約方法 ピアソンVUEのサイト（※10）からログインを続行することでCompTIA側のサイトにリダイレクトされるので、新規にアカウントを作成することで試験情報の紹介や試験予約が可能になります。 注意点 住所は正しく登録しましょう。CBT試験開始前に氏名と住所による身分証明の確認は当然行われますが、合格した場合は数か月後に郵送で資格証が登録している住所に届きますので郵送も可能なように登録する点に注意しましょう。（※11） ※10 ピアソンVUE CompTIA | コンプティア認定試験 ※11 CompTIA 認定証の発送方法 利用したコンテンツ 筆者はTAC社の CompTIA Security X(旧 CASP+)（CAS-004）Web模擬試験 を利用しました。利用してみて評価はかなり高いです。 実際の試験と同じ出題形式でまとまっており、確認と仕上げをするには十分な分量です。 要点と注意点（※12） 問題数は模擬試験2回分。 コンテンツ利用期間は購入してから約2か月の期間で、TAC社の専用Webサイトでの利用となります。 購入後、初回ログインのためのID/Passwordは登録住所に郵送となります。（1週間程度かかります） 事前に細かいところまで知識を詰めたいということであればCompTIA公式のThe Official CompTIA CASP+ Self-Paced Study Guide 書籍 日本語版の利用を検討してもよいと思います。（※13）　筆者は後述のおススメの勉強法でも紹介している通り、本試験のみに合わせた方法はでなくても合格できると考えているため、Study Guideの利用は見送りました。 また、udemyのコンテンツの利用も検討しましたが、以下の理由から筆者は良質なコンテンツを選ぶ難易度が高いと判断したため見送りました。 本試験に適合するe-Learningのコンテンツは現時点で日本語非対応のものしか見当たらなかった。 問題集は、多数存在するが、玉石混交であるため見分けるのが難しい。 ※12 TAC社 CompTIA「Web模擬試験」 ※13 CompTIA jp Store The Official CompTIA CASP+ Self-Paced Study Guide 筆者の前提知識 先の通り筆者はオンプレ＆ クラウド 、ネットワーク＆セキュリティのごちゃまぜエンジニアです。担務領域に関しては特にこだわりなくなんとなく興味を持った資格は取得してます。(※ My credly ) その点を踏まえ、次のセクションの勉強法では各分野の知識を既に習得済みの上級者（CompTIAの想定する10 年間の一般的な IT の実務経験済み）向けの勉強法と、上級者に該当しない中級者向けの勉強法に分けて紹介します。 AWS Azure Google CompTIA その他 AWS Certified Solutions Architect - Associate Azure Administrator (AZ-104) Associate Cloud Engineer CompTIA Cloud+ IPA ネットワークスペシャリスト 試験 AWS Certified Security - Specialty Azure Security Technologies (AZ-500) Professional Cloud Security Engineer CompTIA Security+ IPA 情報処理 安全確保支援士 （登録） AWS Certified Advanced Networking - Specialty Azure Network Engineer (AZ-700) Professional Cloud Network Engineer CompTIA CySA+ ---- おススメの勉強法 上級者向け 筆者は受験に至った経緯と前提知識の通り クラウド 、セキュリティ分野は初学ではなくそれぞれの分野で上位資格（ AWS Certified Security - Specialty、Professional Cloud Security Engineer等）を既に取得しています。同じように本試験のレベルと同程度のスキルを既に持っている方は、最初に試験自体について要点を抑えることを推奨します。 本試験の「カバーする領域がどこまでなのか？」を理解する事が重要であり、CompTIA公式のCompTIA Advanced Security Practitioner(CASP+) 認定資格試験出題範囲（※14）を一読してみるのが良いです。とはいえ、流し見しても全く理解は進まないと思いますので、具体的な方法として以下をお勧めします。 末尾に付属している略語リスト、一覧についてわからないものは全部調べてみる。 CASP+(CAS-004) 略語リスト ECDSA、 FPGA 、CASB等明らかに階層が全く違う専門用語が並んでいます。 CASP+ ハードウェアとソフトウェア一覧 略語リストほどピンポイントではないですが、ある程度対象となるようなコンテンツを確認するのに役立ちます。 上記までを完了し、TAC社の問題集を利用した学習を進めれば、最低限の合格ラインには達すると思います。どうしてもこの分野だけわからないということであれば物理インフラやガバナンスだけ追加で勉強する等対策を行うのがよいです。また、本試験でも海外の法律に関連した問題が出題されることがあるため、問題集で出題されるものは最低限は押さえておきましょう。 ※14 CompTIA CASP+出題範囲 中級者向け 中級者については特定の分野では知見がある方や クラウド やセキュリティに関わって間もない方もいらっしゃると思いますが、基本的には広範囲で知識が足りない可能性が高いです。 そのため、本試験への直接チャレンジは難しいかと思いますので、先に クラウド 分野、インフラ分野、セキュリティ（ガバナンス）分野で学習を行い、それぞれ1つくらい資格を取得する流れをお勧めします。以下が筆者が考えている資格例です。 クラウド 分野 インフラ分野 セキュリティ （ガバナンス）分野 CompTIA Cloud+ CompTIA Network+ CompTIA Security+ （及び CySA+） AWS Certified Solutions Architect - Associate Cisco Certified Network Associate IPA 情報処理 安全確保支援士試験 Azure Administrator (AZ-104) IPA ネットワーク スペシャ リスト試験 ---- 上記レベルの資格をそれぞれの分野で取得していれば（ないしそれに準ずる知識があれば）本試験を受験できるレベルに達しています。先の紹介している産業向けインフラ領域や国外の法律を除き全く知らない技術が出てくることはほぼないと思います。 筆者は本試験に関する事前知識としては スペシャ リストレベル（とりわけ クラウド 領域）の知識は不要と考えています。出題範囲が広く習得しないといけない分野が多岐にわたるため、各領域のエントリー～中級レベルで下地となる知識を備えた上で、「上級者向け」の対策を行い、本試験に合わせるという勉強法が良いと思います。 受験所感 筆者は無事1回目で合格できましたが、事前の予想通り、出題範囲は広く、問題数はやはり多かったです。以下、受験後の所感です。 問題数が多いため全体の時間配分に注意する。 何度も読み直してもいまひとつ理解できない問題は出題される。 日本語翻訳の問題もありますが、回答者として見るべき視点が違ったのではないかと振り返って思います。 選択肢がかなり似ている問題も存在する。 消去法で対応するしかありませんが、問題で何を求めているかを再確認しましょう。同一の技術用語が含まれている場合でも求められている使用法が異なるケースも存在します。 総評（有用か否か？） ここまで読んでいただいて「かなり面倒な試験なのでは？」、「取得する意味あるの？」と思われた方もいるかと思いますので、筆者なりのメリット、デメリットを紹介したいと思います。 メリット 表面的なセキュリティに詳しいだけでは合格できないため、IT全般の領域で知識レベルは相当高いことが証明できる。少なくとも筆者の評価は高いです。 おススメの勉強法でも示した通り、 クラウド とオンプレの両方で知見を積んでいる必要があり、とりわけハイブリッド クラウド の設計・運用ではかなり有用なセキュリティ技術者であることを証明できます。 情報処理安全確保支援士試験をはじめとした IPA の試験でも本試験ほどの技術的知識を求められないため、代替できるものはない認識でいます。試験合格後に登録のプロセスが必要ということもないため、筆者のようにライトにチャレンジしてみようという受験者にとって本試験は好ましい立ち位置に見えます。 海外では評価される資格である。 日本国内では IPA 情報処理安全確保支援士試験が有力ですが、それを補完する意味で持っていても損はないです。（海外の企業と仕事をする予定のかたは是非チャレンジしましょう！） デメリット 受験費用 AWS 、Azure試験の上級資格の試験料よりも高額となるため、受験回数がかさむことは避けたいです。（※15） 対策としては1回目の試験分は支払う前提になりますが、CompTIA公式のリテイクキャンペーンや格安のバウチャーチケットを利用することで2回目の受験費用を抑える方法が考えられます。 必要とされる勉強量が多い。 合格レベルに達するために複数の技術領域、用語を多く理解する必要があります。おススメの勉強法で紹介した通り、本試験のみの勉強に時間を費やすのではなく、他の中級者向け資格を経由することでステップを踏み能力を底上げすることで対応しましょう。 ※15 CompTIA 認定資格試験価格 最後に 読了いただきありがとうございました。筆者はCompTIAのCloudNetX（※16）やISC2のCCSP試験にも今後チャレンジ予定ですので受験後に今回の記事に加えてアップデートできればと思います。 ※16 SecurityX認定資格の提供開始でCompTIA Xpert シリーズが拡充 執筆： @sakurai.ryo レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

はじめに クロス イノベーション 本部 クラウド イノベーション センターの宮崎博寿です。 AWS アカウントのコストは「いざ調べよう」と思うと AWS Console → Cost Explorer を開き、フィルタを選び…と若干手間が掛かります。 コンソールへログインし、Cost Explorer でコストを確認するという毎回同じ手順を踏むのは、いくつもアカウントを見ている方だと若干億劫になってしまうかもしれません。 Amazon Q Developer in chat applications (旧称: AWS Chatbot) を Teams チャネルに連携すると、この作業をチャットの質問だけで完結できるようになります。 Cost Explorer データを用いて AWS のアカウントのコストに関連する情報を 自然言語 で質問することで、実際の数値を見ることができるためコスト確認にかかる手間を少なくすることができます。 タグ単位・サービス単位のコスト集計や増減分析まで 自然言語 で回答してくれるため、単に数字をみるだけのコスト確認の作業では、 CLI やコンソール操作をゼロに近づけられます。 非エンジニア・エンジニア問わず様々なロールの方が、気軽に AWS アカウントのコストをTeams等のチャネルから確認できるようになるのはかなり楽になるポイントだと思います。 本記事では Amazon Q Developer in chat applications (旧称: AWS Chatbot)の設定方法と、実際に 自然言語 （英語）で質問した内容を共有したいと思います。 はじめに 前提作業 セットアップ手順 Teams側の設定① AWS側の設定 Teams側の設定② Teamsから実際にコストを確認してみる まとめ 参考記事 前提作業 Amazon Q Developer in chat applicationsが使用するIAMロールを下記のポリシーを付与して事前に作成しておく。 このIAMロールは後ほど設定でアタッチする。 信頼ポリシー json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "chatbot.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } コスト参照用ポリシー { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCostExplorerAPIAccess", "Effect": "Allow", "Action": [ "ce:GetCostAndUsage", "ce:GetCostForecast", "ce:GetDimensionValues", "ce:GetCostCategories", "ce:GetTags", "ce:GetReservationPurchaseRecommendation", "ce:GetSavingsPlansPurchaseRecommendation" ], "Resource": "*" }, { "Sid": "AllowCostOptimizationHubAccess", "Effect": "Allow", "Action": [ "cost-optimization-hub:ListRecommendations", "cost-optimization-hub:ListRecommendationSummaries", "cost-optimization-hub:GetRecommendation" ], "Resource": "*" }, { "Sid": "AllowComputeOptimizerRecommendations", "Effect": "Allow", "Action": [ "compute-optimizer:GetEC2InstanceRecommendations", "compute-optimizer:GetEBSVolumeRecommendations", "compute-optimizer:GetLambdaFunctionRecommendations", "compute-optimizer:GetIdleRecommendations", "compute-optimizer:GetEffectiveRecommendationPreferences" ], "Resource": "*" } ] } AmazonQFullAccessの AWS 管理ポリシー 下記を参照してください。 https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonQFullAccess.html その他作業・考慮事項 Cost 配分タグの有効化：タグベース集計を行う場合、対象タグを Cost Allocation Tag として事前に有効化しておく。 サービスの有効化の確認：Cost Explorer / Compute Optimizer / Cost Optimization Hub を Billing 画面から「有効化」。 言語は英語：2025-06 現在、チャットは英語での質問が必要。 セットアップ手順 Teams側の設定① Amazon Qと連携したいチャネルのリンクを取得する - 連携したいTeamsチャネルのその他のオプションを押下 - その後チャネルへのリンクを取得を押下し、リンクをコピーして手元に控える 下記画面でコピーを押下 AWS 側の設定 コンソールから Amazon Q Developer in chat applicationsと検索する。 ※他の Amazon Qサービスと間違えないように その後、 Amazon Q Developer in chat applications (旧称: AWS Chatbot) の画面に戻り設定を進める。 ・設定名：任意の名前で入力 ・ログ記録：任意 アクセス許可の設定を行います ・ロール名：事前に作成したCost Explorer API （ce:GetCostAndUsage など）や Cost Optimization Hub / Compute Optimizer にアクセスする権限を付与したロールを選択します。 ・ポリシーテンプレート：ユーザガイドを参照し必要に応じてポリシーを追加します。 その後ガードレールを設定します。AmazonQFullAccessやReadOnlyAccessはコスト系の情報を参照するのに必須のためマストで選択します。 通知オプションを任意で選択後、設定ボタンを押下することで Amazon Q側の設定は完了です。 Teams側の設定② 最後にTeamsに戻り設定したチャネルへ Amazon Qのボットを追加します。 下記の画面が出たら設定完了です。 Teamsから実際にコストを確認してみる 先月のコストについて聞いてみる ⇒先月のコストについて返してくれました。Cost関連の API を使用して情報を AWS アカウントから取ってきてくれていることが分かりますね。 ※アカウントIDの部分をマスクしています。 特定の月（3月）のトータルコストとサービス別のコスト内訳について聞いてみる。 ⇒正しくトータルのコストと、サービス別にコストについて教えてくれました。 まとめ 今回はTeamsのチャネルから AWS アカウントのコスト確認を、 Amazon Q Developer in chat applications (旧称: AWS Chatbot) を用いて実現する方法を解説しました。 現在、 Amazon Q Developer IDE や Amazon Q Developer CLI では 自然言語 として日本語でプロンプトを投げることが可能なっており、機能面も MCP 対応や各種ツールによるファイル操作等強力なサービスとなっています。 コスト確認も日本語のプロンプトで容易にすることが可能です。 一方で、 IDE や CLI を使わないビジネスロールの方にも チャネルで@AmaonQとメンションして 自然言語 で質問するだけで AWS アカウントのコスト情報を見ることができるのは大きなメリットだと思います。 コスト以外でもセキュリティの推奨事項やHealthイベントを確認する等の活用もあるでしょう。（私もこれから色々試して見ようと思います。） Amazon Q Developer in chat applications (旧称: AWS Chatbot) は現状日本語対応しておりませんが、（2025年7月3日時点）今後の対応に期待して今のうちにセットアップしてみるのはどうでしょうか。 （日本語対応することを願っています！！） この記事が参考になったら幸いです。 参考記事 https://docs.aws.amazon.com/chatbot/latest/adminguide/understanding-permissions.html#:~:text= https://docs.aws.amazon.com/ja_jp/chatbot/latest/adminguide/service-rename.html https://docs.aws.amazon.com/ja_jp/chatbot/latest/adminguide/teams-setup.html https://docs.aws.amazon.com/it_it/chatbot/latest/adminguide/asking-questions.html#service-questions-q#:~:text=1,policy%20to%20your%20IAM%20role 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @miyazaki.hirotoshi レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ）

こんにちは。 電通 総研ITの寺尾です。 今回は IntelliJ の インスペクション（コード検査）機能 の実装方法についてご紹介します。 前回はこちら： IntelliJプラグイン開発の始め方～ラインマーカー編～ インスペクション（コード検査）とは インスペクション とは、 IntelliJ 上で特定の条件を満たす箇所にエラー、警告を表示する コード検査機能 です。 開発者はこのハイライトを目印にしてコード修正をすることが多いかと思います。 IntelliJ プラグイン でも独自の検査ルールを用意し、エラーハイライトや警告表示を行えます。 公式ドキュメント 実装前に知っておくこと 前回と同様に、本記事でもKotlinでの実装例を提示します。 Kotlinプロジェクトに関する内容は、アクション機能編の 実装前に知っておくこと をご参照ください。 実装 ゴール 今回は、DAOメソッドに対する SQL テンプレートの存在をチェックする検査機能を実装します。 クイックフィックスの実装については省略させていただきますので、ご了承ください。 事前準備 インスペクション機能はプロバイダークラスを実装して実現します。 まずは以下の準備から始めていきましょう。 InspectionToolProvider のサブクラス AbstractBaseJavaLocalInspectionTool のサブクラス JavaElementVisitor のサブクラス インスペクション機能の説明HTMLファイル プラグイン 設定登録 コード検査機能では、プロバイダークラスを起点に以下の流れでコード検査処理を呼び出します。 Provider⇒Inspection⇒Visitor plugin.xml には、以下のように <inspectionToolProvider> タグを使ってプロバイダークラスを登録します。 プロバイダークラスは IntelliJ の拡張ポイントとして登録するため、 <extensions defaultExtensionNs="com.intellij"> タグの中に記述します。 <inspectionToolProvider implementation = "org.domaframework.doma.intellij.inspection.dao.provider.SqlFileExistProvider" /> それでは各実装について一つずつ見ていきます。 プロバイダークラスの実装 設定ファイルに登録するプロバイダークラスの実装から始めていきます。 ここでの実装はとてもシンプルで、以下のようにオーバーライドメソッドでインスペクションクラスのリストを返すのみになります。 class SqlFileExistProvider : InspectionToolProvider { override fun getInspectionClasses(): Array <Class< out LocalInspectionTool>> = arrayOf( SqlFileExistInspection :: class .java, ) } インスペクションクラスの実装 プロバイダークラスから渡されるインスペクションクラスを実装します。 このクラスでは、インスペクション名称やグループなどの基本情報の定義と、コード内の要素を探索して処理するVisitorクラスを呼び出します。 ここで定義したインスペクション情報は、 IntelliJ の 設定 > エディター > インスペクション で表示される情報です。 また shortName はインスペクションの識別名となり、後ほど作成するHTMLファイル名は識別名と一致している必要があります。 class SqlFileExistInspection : AbstractBaseJavaLocalInspectionTool() { // インスペクション表示名 override fun getDisplayName(): String = "Check existence of SQL file" // インスペクション名 override fun getShortName(): String = "org.domaframework.doma.intellij.existsqlchecker" 　　 // インスペクショングループ名 override fun getGroupDisplayName(): String = "DomaTools" // デフォルト有効フラグ override fun isEnabledByDefault(): Boolean = true 　　 // デフォルトのエラーレベル override fun getDefaultLevel(): HighlightDisplayLevel = HighlightDisplayLevel.ERROR 　　 // Visitorオブジェクトの取得 override fun buildVisitor( holder: ProblemsHolder, isOnTheFly: Boolean , ): PsiElementVisitor = SqlFileExistInspectionVisitor(holder, this .shortName) } Visitorクラスの実装 コード検査ロジック本体をVisitorクラスに実装します。 Visitorクラスは様々な種類がありますが、今回は Java で実装されたDAOファイルに対する要素の探索を行うため、 JavaElementVisitor のサブクラスとして実装します。 このクラスはサポートしている要素ごとにvisitメソッドをオーバーライドし、その要素に対して処理を行います。 JavaElementVisitor のサブクラスでは、例えば以下の要素の探索が可能となっています。 クラス定義 メソッド定義 メソッド アノテーション メソッドパラメータリスト メソッドパラメータ コードブロック 定義全体、またはその子要素など細かいメソッドが用意されています。 今回は アノテーション も含めたメソッド定義の情報を扱うため、 visitMethod のみオーバーライドします。 コード検査の条件として、以下のチェックロジックを実装します。 対象が Java のDAOファイルである SQL テンプレートが必要なメソッドである 適切なパスに SQL ファイルが配置されている、または SQL アノテーション が付与されている class SqlFileExistInspectionVisitor( private val holder: ProblemsHolder, private val shortName: String , ) : JavaElementVisitor() { // メソッド定義要素への処理 override fun visitMethod(method: PsiMethod) { super .visitMethod(method) // チェック対象のファイルか val file = method.containingFile if ( ! isJavaOrKotlinFileType(file) || getDaoClass(file) == null ) return // チェックロジックの実装 val psiDaoMethod = PsiDaoMethod(method.project, method) if (psiDaoMethod.isUseSqlFileMethod()) { checkDaoMethod(psiDaoMethod) } } private fun checkDaoMethod(psiDaoMethod: PsiDaoMethod) { val identifier = psiDaoMethod.psiMethod.nameIdentifier ?: return // SQLファイルがない場合、エラーハイライトする if (psiDaoMethod.sqlFile == null ) { ValidationSqlFileExistResult( psiDaoMethod, identifier, shortName, ).highlightElement( holder, ) } } } コンスト ラク タパラメータ サンプルコードでは、Visitorクラス内でエラーハイライト用のオブジェクトを作成し、 インスペクションクラスから渡された ProblemsHolder に格納する処理を行います。 デフォルトでエラーレベルを設定していますが、識別名 shortName を受け取り、ハイライトの種類を IntelliJ の設定から判定するための処理で利用します。 class SqlFileExistInspectionVisitor( // エラーハイライトオブジェクトを格納する private val holder: ProblemsHolder, // エラーレベルを設定から取得するためのインスペクション識別名 private val shortName: String , ) : JavaElementVisitor() 検査対象のチェック 以下のオーバーライドメソッドで、メソッド定義要素への処理を実装します。 まずはチェック対象のファイルであるかを検証し、対象でなければ後続処理には入りません。 対象のチェック方法については、以前にもご紹介したファイルタイプチェック実装などを参考にしてください。 IntelliJプラグイン開発の始め方～アクション機能編～ // メソッド定義要素への処理 override fun visitMethod(method: PsiMethod) { super .visitMethod(method) // チェック対象のファイルか val file = method.containingFile if ( ! isJavaOrKotlinFileType(file) || getDaoClass(file) == null ) return // チェックロジックの実装 val psiDaoMethod = PsiDaoMethod(method.project, method) if (psiDaoMethod.isUseSqlFileMethod()) { checkDaoMethod(psiDaoMethod) } } アノテーション 付与のチェック メソッドに付与されている アノテーション が、 SQL テンプレートを必要としていることをチェックします。 メソッド アノテーション 要素の判定は、以下のように実装できます。 独自に用意している PsiDaoMethod クラス経由で アノテーション タイプを取得し、 最終的に SQL テンプレートが必要な アノテーション であるかを判定しています。 fun getPsiAnnotation(element: PsiModifierListOwner): PsiAnnotation? = AnnotationUtil.findAnnotation( element, // PsiMethod（メソッド定義要素） annotationName, // 取得したいアノテーションのクラス名 ) SQL テンプレートが必要なメソッドであることを確認出来たら、次に SQL ファイルの検索を行います。 SQL ファイルの検索 DAOメソッドのファイルパス、メソッド名を基に SQL ファイルが適切に配置されていることをチェックします。 PsiDaoMethod クラスの処理で取得した、リソース ディレクト リ内にある SQL ファイル情報を保持しています。 この部分はアクション機能の実装と同様のロジックとなりますので、以下の記事も参考にしてみてください。 IntelliJプラグイン開発の始め方～アクション機能編～ private fun checkDaoMethod(psiDaoMethod: PsiDaoMethod) { val identifier = psiDaoMethod.psiMethod.nameIdentifier ?: return // SQLファイルがない場合、エラーハイライトする if (psiDaoMethod.sqlFile == null ) { ValidationSqlFileExistResult( psiDaoMethod, identifier, shortName, ).highlightElement( holder, ) } } エラーハイライト 独自に用意している ValidationSqlFileExistResult クラス内では、 holder にエラー情報を登録する処理を行っています。 この登録処理を行うことで、エディタ上にエラーハイライトが表示されるようになります。 エラー情報登録処理部分のみのサンプルを記載します。（以下は highlightElement() によって呼び出される処理です）。 // ValidationSqlFileExistResultでのコンストラクタで受け取ったidentifyをエラーハイライト対象にする val project = psiDaoMethod.psiMethod.project holder.registerProblem( identify, // エラーハイライトする要素 MessageBundle.message( "inspection.invalid.dao.notExistSql" ), // エラーメッセージ problemHighlightType(project, shortName), // エラーレベルを取得して設定 highlightRange, // エラーハイライトするTextRange ) problemHighlightType() では、インスペクション識別名を基に IntelliJ の設定からエラーレベルを取得します。 // エラーレベルを設定から取得 private fun getInspectionErrorLevel( project: Project, inspectionShortName: String , ): HighlightDisplayLevel? { val profileManager = InspectionProfileManager.getInstance(project) val currentProfile = profileManager.currentProfile val toolState: ToolsImpl? = currentProfile.getToolsOrNull(inspectionShortName, project) return toolState?.level } protected fun problemHighlightType( project: Project, shortName: String , ) = when ( // 設定から取得したエラーレベルによって、ハイライト設定を返す getInspectionErrorLevel( project, shortName, ) ) { HighlightDisplayLevel.Companion.ERROR -> ProblemHighlightType.ERROR HighlightDisplayLevel.Companion.WARNING -> ProblemHighlightType.WARNING else -> ProblemHighlightType.WARNING } 【補足】 エラーに対してクイックフィックスを提案したい場合、 holder.registerProblem() にクイックフィックスオブジェクトを渡します。 クイックフィックスの実装は、任意のファクトリクラスを作成して LocalQuickFix サブクラスを返すようにします。 詳細は 公式ドキュメント をご参照ください。 インスペクション機能の説明HTML 実装したインスペクション機能は、 IntelliJ の設定画面に追加されます。 この設定画面で表示される詳細な機能説明を、HTMLファイルに記載します。 HTMLファイルはリソース ディレクト リの inspectionDescriptions フォルダに配置してください。 今回は簡潔に文章のみの説明をしていますが、 <code> タグを使うことでコードブロックの記述も可能です。 < html lang = "en" > < body > < p > This inspection ensures that a DAO method has a corresponding SQL file. If the SQL file is missing, a warning or error is displayed, and a quick-fix is provided to generate the missing file. </ p > </ body > </ html > 【補足】 インスペクションクラスで表示されるファイルアイコンをクリックすることで、対応するHTMLファイルの作成、表示が可能です。 動かしてみる コード検査機能で、 SQL ファイルのないDAOメソッドがエラーハイライトされることを確認してみましょう！ デバッグ 起動方法は前回と同じく、 デバッグ起動する で実行してください。 参考:：「 Doma Tools」実装コード 「 Doma Tools」の同様のインスペクション機能は以下コードで実装しています。 SqlFileExistInspectionVisitor まとめ コード検査機能の実装のポイントは、以下4点になります。 コード検査のように状態監視を行う機能では、プロバイダークラスを起点にした処理を行う インスペクションクラスやHTMLで、検査機能の情報を定義する メインのチェック処理はVisitorクラスで担当する どの要素がどのPSI要素クラスとして認識されるかを確認しておく 一部の IntelliJ 機能の実装では複数のクラスを用意する必要がありますが、 クラスごとに適切な役割を持たせることが保守性を高めるポイントになります。 また IntelliJ プラグイン のコードの解析を伴う処理において、 PSI要素クラスの利用が必須となりますが、コード検査機能の実装は大変良い学習機会になると思います。 さいごに 今回はコード検査機能の実装についてご紹介しました。 コード検査はビルド前にエラーを検知できることができ、開発効率化や実装者の負担を減らせる有用な機能です。 ご紹介できなかったクイックフィックスの実装などにも挑戦して、より良い開発体験を実現してみてください。 レビューも投稿していただけますと大変励みになります🙇‍♀️ Doma Tools マーケットプレースページ 本 プラグイン は OSS として Domaコミュニティ へ寄贈されています。 不具合修正や機能要望、ディスカッションにもぜひご参加ください。 採用ページ 執筆： @terao.haruka レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

こんにちは。コーポレート本部 サイバーセキュリティ推進部の耿です。 GitHub で管理しているプロジェクトの依存関係（パッケージ）を更新する場合、 Dependabot Version Updates で自動化することがあります。このDependabotについて、以前の記事( GitHub Actions の更新への追随とリスク低減のバランスを考える )で触れたcooldown機能が 正式リリース されましたので早速試してみました。 cooldown機能とは 機能の詳細 使い方 実際に試してみた npmパッケージの更新 GitHub Actions の actionの更新 まとめ cooldown機能とは 公式発表 からの引用です。 The cooldown feature allows you to configure a minimum age requirement before Dependabot creates a pull request for a newly released dependency . This is perfect for folks using version updates with: ・Mature or stable projects that prefer conservative dependency updates. ・High-frequency packages that frequently release updates. ・Teams that want to avoid patch-level noise while staying current. リポジトリ で使用している依存関係（パッケージ）を新しいバージョンに更新するPRをDependabotが作成する際、（リリースからの）経過時間の最小値を設定できる機能です。 想定されている ユースケース は以下とのこと。 依存関係の更新を保守的に行いたい、成熟したプロジェクトや安定したプロジェクト 高い頻度でリリースがあるパッケージを利用している場合 パッケージを最新の状態を保ちつつ、大量のパッチバージョンの更新によるノイズを減らしたい場合 補足として 以前の記事 に書いたように、PR作成までに一定期間待機することによって、その間に新バージョンにおけるバグや 脆弱性 、悪意のある改ざんが検知・解決されることにも期待できます。 機能の詳細 公式ドキュメント およびベータリリースについて記載された Issue のコメントを参考にします。（公式ドキュメントがまだ日本語訳されていない場合は英語でご覧ください） Dependabotは dependabot.yml に設定された更新頻度（ schedule.interval ）のタイミングで起動します。起動時にcooldownの設定値を考慮し、条件を満たす更新のみPRを作成するという仕組みです。 Security Updates に cooldownは適用されません。 cooldown期間を経過したかどうかに関係なく、Version Updatesは 脆弱性 のあるバージョンに対してはPRを作成しません。 ＜例＞更新頻度を日次( daily )、cooldownを3日と設定し、使っているソフトウェアのバージョンが現在 1.1.0 の場合 ケース1：通常のバージョンアップに対する挙動 7月1日：バージョン 1.1.1 がリリースされる。cooldown期間を経過していないのでPRは作成されない 7月3日：バージョン 1.1.2 がリリースされる。 1.1.1 も 1.1.2 もcooldownの期間を経過していないのでPRは作成されない 7月4日： 1.1.1 がcooldownの期間を経過したためPRが作成される 。 1.1.2 はcooldownの期間を経過していないのでPRは作成されない 7月6日： 1.1.2 もcooldownの期間を経過したためPRが作成される 。 ケース2：新バージョンに 脆弱性 が発見された時の挙動 7月1日：バージョン 1.1.1 がリリースされる。cooldown期間を経過していないのでPRは作成されない 7月2日： 1.1.1 に 脆弱性 が発見される 。cooldownの期間を経過していないのでPRは作成されない 7月3日： 脆弱性 を修正した 1.1.2 がリリースされる。 1.1.1 も 1.1.2 もcooldownの期間を経過していないのでPRは作成されない 7月4日： 1.1.1 がcooldownの期間を経過したが、 脆弱性 があるためPRは作成されない。 1.1.2 はcooldownの期間を経過していないのでPRは作成されない 7月6日： 1.1.2 がcooldownの期間を経過したためPRが作成される 。 使い方 公式ドキュメントの例を引用します。 dependabot.yml version : 2 updates : - package-ecosystem : "pip" directory : "/" schedule : interval : "daily" cooldown : default-days : 5 semver-major-days : 30 semver-minor-days : 7 semver-patch-days : 3 include : - "requests" - "numpy" - "pandas*" - "django" exclude : - "pandas" cooldown のパラメータは全てオプショナルのようですが、少なくとも default-days semver-major-days semver-minor-days semver-patch-days のどれかは記載しないと cooldown の設定として意味を持たないと思われます。 例の設定の場合、 include ： requests numpy django および pandas から始まるパッケージ（ ワイルドカード * が使用可能）に対して待機時間が設けられます。 exclude ： pandas に完全一致する名前のパッケージには待機時間が設けられません。 semver-major-days ： メジャーバージョンアップデートは30日の待機時間が設定されます。 semver-minor-days ： マイナーバージョンアップデートは7日の待機時間が設定されます。 semver-patch-days ： パッチバージョンアップデートは3日の待機時間が設定されます。 default-days ： セマンティックバージョニングをサポートしていないパッケージマネージャ（ GitHub ActionsやDockerなど。 ドキュメント 参照）ではあらゆる種類のアップデートに対して適用される待機時間です。セマンティックバージョニングをサポートしているパッケージマネージャでは semver-major-days semver-minor-days semver-patch-days いずれかの記載がない場合、その種類のアップデートには default-days の待機時間が適用されます。 実際に試してみた 実験用に GitHub リポジトリ を作成し、いくつかのnpmパッケージと、 GitHub Actionsの サードパーティ アクションを利用するように構成しました。 cooldown 機能を利用するために、 dependabot.yml は次のように書きました。 dependabot.yml version : 2 updates : - package-ecosystem : "github-actions" # GitHub Actionsに対する更新ルール directory : "/" schedule : interval : "daily" cooldown : default-days : 3 # 待機期間。検証ではすぐに結果を知りたいので3日にしてみます - package-ecosystem : "npm" # npm に対する更新ルール directory : "/" schedule : interval : "daily" cooldown : default-days : 3 # 待機期間 npmパッケージの更新 cdk-nag というパッケージの v2.36.30 は 2025/6/30 9:16 にリリースされましたが、DependabotがPRを作成したのは 2025/7/3 21:59 でした。 cooldownを設定していない時はリリースから1日以内にPRが作成されていたので、ちゃんとcooldownが効いていることがわかります。 GitHub Actions の actionの更新 GitHub Actions の actionの更新でも同じことを確認できました。 電通 総研が公開している サードパーティ アクション dentsusoken/build-and-scan-image （コンテナイメージに対するhadolint、dockle、trivyによるスキャンを一括で実行できるaction）をコミットハッシュ（SHA）でバージョン指定し、ワークフローを作成しています。 デフォルトブランチに新しいコミット 990b445 は2025/6/30 9:43 にプッシュされましたが、DependabotがPRを作成したのは 2025/7/3 21:55でした。 まとめ 以前の記事 でも触れたとおり、 GitHub Actions については push など特定の イベントトリガー を使うと、更新されたブランチ（更新された新しいバージョン）のワークフローファイルが実行されます。新しいバージョンに悪意のあるコードが含まれていた場合、 PR が自動作成されただけで悪意のあるコードが自分の リポジトリ 上で実行される可能性があるため、cooldown機能を使って一定期間はそもそもPR自体を作成しないことは、 GitHub Actionsが侵害された場合に対する防御として有効だと考えられます。 Dependabot Version Updatesを使っている場合は、セキュリティの観点でもぜひ cooldown 機能の使用を検討してみてください。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 執筆： @kou.kinyo レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

こんにちは、スマート ソサエティ センターの飯田です。 今回は、 Google CloudのCloud Runと MCP サーバ関連で下記の２つをご紹介します。 Google CloudのCloud Run上に MCP サーバを ホスティング ホスティング された MCP サーバでCloud Runを操作する きっかけは、この Google のテックブログでして、CloudRun× MCP を触ってみようと思いました cloud.google.com MCP （Model Context Protocol）とは MCPはアプリケーションがLLMにコンテキストを提供する方法を標準化するオープンプロトコル（anthropicより引用） です。 誤解を恐れずに簡単に言うと、これまで各社がバラバラに作っていた「LLMと外部ツールを繋ぐ仕組み」に共通の規格を設けようという取り組みです。この規格に沿ってツール（プログラム）を作っておけば、様々なLLMから再利用しやすくなり、開発のエコシステムが活性化する、というメリットがあります。 Cloud Runとは Cloud Runは、 Google Cloudが提供するフルマネージドなサーバーレスプラットフォームです。コンテナ化されたアプリケーションを自動的にスケールさせながら実行できます。 サーバーの管理を気にする必要がなく、使った分だけの課金なので、コストを抑えつつ、高い拡張性を持つアプリケーションを開発できるのが特徴です。　 cloud.google.com 【実践】Cloud Runに MCP サーバを ホスティング 今回は、主に下記の２つのページを参考にしています。2つの公式ドキュメントに沿って実施していけば動かせると思います。 https://cloud.google.com/run/docs/host-mcp-servers?hl=ja https://github.com/GoogleCloudPlatform/cloud-run-mcp 全体構成は下記のイメージです。 細かい手順はREADMEに書いてあるので、StepByStepでは書きませんが、大まかな流れを・・・。 1. MCP サーバをCloudRunに ホスティング する gcloud run deploy cloud-run-mcp --image us-docker.pkg.dev/cloudrun/container/mcp --no-allow-unauthenticated この処理では、CloudRunを操作する MCP サーバのDockerコンテナが us-docker.pkg.dev/cloudrun/container/mcp 　に格納されているので、そこからCloudRunにコンテナをデプロイしています。 2. デプロイ結果の確認 GCP コンソールからも確認できます 3. Cloud Run proxyを実行し、認証させる gcloud run services proxy cloud-run-mcp --port=3000 --region=REGION --project=PROJECT_ID 今回はまず動かしてみるということで、簡単に動作できるCloud Run proxyで動作させます。 Cloud Run proxyは、Cloud Runサービスの認証を容易にするためのプロキシサービスです。Cloud Run 起動元ロールなどが付与されているユーザで実行すると、ローカルプロキシ経由で、CloudRunにアクセスできます。 プロダクションではIdentity-Aware Proxy（IAP）やIdentity Platform を使うと良いと思います 4. MCP クライアントの設定 私は VSCode をつかっているので、 VSCode の設定をします。　Settings＞ MCP で検索＞Edit in setting. json 5.　実行してみる MCP サーバの設定が終わったので、実際にCloudRunの MCP サーバを動かしてみます CloudRunの情報が取れており、ちゃんと動いていますね。 最後に、CloudRunのログも確認してみます。 MCP は JSON -RPCでやりとりをしているので、ログにもしっかりと残っています。無事に動作しているようです。 これで、CloudRunへのデプロイと MCP サーバをつかったCloudRunの操作ができました！ ただ、 MCP サーバのデプロイに関しては、公開されたDockerコンテナを配置しただけなので、 実際に自分で開発したときにどうなるの？・・・ということころも気になったので、自分で作成した MCP サーバの ホスティング も試してます オリジナルの MCP サーバを ホスティング する（ Python でもやってみる） 公式のサンプルではNotejsの MCP サーバを ホスティング していたので、 Python の MCP サーバを ホスティング してみます。 Python で MCP サーバを自作する際、 FastMCP が便利です。 Python のシンプルなWebフレームワークであるFastAPIベースになっていて、 API をそのまま MCP のインターフェースに置き換えることができるライブラリです。 1. 実装をする ほぼ、 チュートリアル そのままですが、こんなイメージで MCP サーバを作れます これは単純に足し算しているだけです・・・ あとは、ClourRunで動かすためのDockerFileを準備するだけです @mcp.tool() def add(a: int, b: int) -> int: """二つの数字の足し算""" return a + b if __name__ == "__main__": mcp.run(transport="sse", host="0.0.0.0", port=os.getenv("PORT", 8080)) 2. . CloudRunにデプロイする レジストリ に登録してないので、ソースからCloudRunにアップロードします gcloud run deploy mycloudrun --no-allow-unauthenticated --source . 4. Cloud Run proxyを実行し、認証させ、 VScode でアクセスする gcloud run services proxy mycloudrun --region XXXXXX` 動きました CloudRunのログでも確認ができました add' called with numbers '3' and '5' やりました。これでCloudRun上で MCP サーバを ホスティング できました！ TIPS ・ MCP サーバを開発する際、同じ VScode のWindowで作業をしていると、開発中のコードを利用してしまうことがあるので、開発と MCP サーバのテストは別Windowの VSCode を使用することをお勧めします ・ MCP を明示的に指定して呼ぶのが難しい場合は、 VSCode の右下のハンマーのところをクリックして、使用する MCP サーバやToolを絞り込むと呼び出してくれやすくなります さいごに： MCP サーバをCloudRunに ホスティング する意義とは？ AzureFunctions でも MCP を ホスティング できるように、サーバレス環境に MCP サーバを ホスティング できるようになってきています。 MCP をCloud Runのようなサーバーレス環境で ホスティング することには、実用面でも大きなメリットがあるのではないかと思っています。 メリット1：利用者の裾野を広げる 現状、 MCP ツールを利用するにはnpmなど専門的な開発環境の準備が必要な場合があり、非エンジニアの方にはハードルが高いのが課題です。 MCP サーバーをCloud Run上で ホスティング すれば、利用者は Webブラウザ などからアクセスするだけで済み、サーバーの構築や管理を意識する必要がなくなる可能性が高いと思っています（ClientもWebアプリで作成できれば）。これにより、ビジネス職の人々も手軽にLLMの連携機能を活用できるようになるのではないでしょうか？ メリット2：セキュリティの一元管理と強化 個人のPCにツールをインストールする方法では、セキュリティ対策が各々の環境に依存してしまいます。Cloud Runであれば、IAMと連携して「誰がどのツールを使えるか」というアクセス権限をサーバー側で一元的に管理できます。これにより、企業ユースでも安心して利用できる MCP 基盤に１歩近づくことができるのではないかとおもっています。 ※セキュリティ面では他にもさまざまな課題がありますが おまけ なぜか、Geminiに MCP サーバについて尋ねると、なぜかマ イクラ の MCP について教えてくれます。私がマ イクラ よくやっているせいなのでしょうか？笑 MCP ( Minecraft Cloud Proxy) は、 Minecraft サーバーの管理を効率化するためのプロキシサーバーです。 最後まで読んでいただき、ありがとうございました。 ↓ のスターを押していただけると嬉しいです。励みになります。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @iida.michitaka7b3a3dd24e9c454b 、レビュー： 寺山 輝 (@terayama.akira) （ Shodo で執筆されました ）

こんにちは、スマート ソサエティ センター サステナビリティ ソリューション部の田口和駿です。 本記事では弊社の自社サービスCIVILIOSにおける OpenID Connectの活用方法を紹介します。 なお、本記事でご紹介する情報は2025年5月時点のものとなります。 CIVILIOSとは 弊社が開発した都市OSである CIVILIOS （シビリオス）は、そこに暮らす人に軸足を置きつつ、それぞれの 自治 体の環境にアジャストした最適なデータ連携基盤を提供する無二のソリューションです。 CIVILIOSの特徴として以下のようなものがあります。 内閣府 「 スマートシティリファレンスアーキテクチャ 」に準拠 オープンデータ、パーソナルデータの双方の管理が可能 AWS Well-Architected Framework に準拠する高品質なサービスを提供 すでに導入済のサービスと組み合わせが可能 デジタル庁のデジタル実装の優良事例を支える サービス／システムのカタログ に掲載 CIVILIOSは以下の主要な機能を持っています。これらの機能はビルディングブロック方式と呼ばれる 疎結合 なシステム構築によって、新規機能の追加や不要機能のオミットなど組み換えに対して柔軟に対応できます。 ID連携機能 認証情報を提供するIDプロバイダー機能(CIVILIOS-ID)を利用することで、 シングルサインオン (SSO)機能を実装できます。これにより、住民はサービス毎にログインする必要がなくなります。 住民ポータル機能 住民一人ひとりに合わせた情報提供が可能で、事業が提供するサービスとの連携も実現します。住民は自分の属性や興味に応じたお知らせを受信でき、個人情報の連携可否を設定できます。 オプトイン設定 住民本人の同意の上で、登録された個人情報を各サービスにセキュアに連携する機能を搭載しています。これにより、安心・安全にサービスを利用できます。 オープンデータアップロード機能 自治 体が 保有 するデータを効率的に管理・共有します。オープンデータを CSV 形式でアップロードし、NGSI形式に変換することで、データの標準化と一元管理が可能になります。 ダッシュ ボード機能 自治 体が提供するサービスの利用状況や運用成果を可視化する機能です。各サービスのKPIに対する達成度をリアルタイムで確認することができ、サービスの効果や改善点を視覚的に確認できます。 詳しくは弊社の CIVILIOSに関するウェブサイト をご確認ください。 OpenID Connectとは OpenID Connect(OIDC)とはOAuth 2.0をベースにした認証 プロトコル で、ユーザーの アイデンティティ 情報を安全に共有するための仕組みです。OIDCは、ユーザーが一度ログインすると、その認証情報を使って他のサービスにアクセスできるようにします。具体的には以下のような手順で認証を行います。 アクセス要求 ログイン画面などからユーザーがアプリケーションにアクセスを要求します。 認証要求 アプリケーションは OpenID プロバイダーに認証要求を送ります。 ログイン要求 OpenID プロバイダーはユーザーにログインを求めます。 ログイン情報提供 ユーザーがIDやパスワードなどのログイン情報を OpenID プロバイダーに送信します。 ID トーク ンの発行 ログイン情報を使って認証が成功すると、 OpenID プロバイダーはクライアントアプリケーションに認証 トーク ンを発行します。この トーク ンにはユーザーのID トーク ンやアクセス トーク ンが含まれています。 トーク ンの使用 クライアントアプリケーションは認証 トーク ンを受け取り、ユーザーをログインさせます。 OIDCの利点として大きく3つあります。 セキュリティ：パスワードを複数のアプリケーションで使い回す必要がなくなり、セキュリティが向上します。 利便性：OAuth 2.0 をベースにしているため、既存の OAuth 2.0 インフラスト ラク チャと簡単に統合できます。 標準化： OpenID 規格は国際標準団体によって標準化され、世界中の多くの場所で利用されています。 OIDCは多くの企業やサービスで採用されています。例えば、 Google 、 Microsoft 、 Amazon などの大手企業はOIDCを利用してユーザーの認証を行っています。これにより、ユーザーは一度ログインするだけで、複数のサービスにアクセスできます。また、OIDCは オープンソース のライブラリや フレームワーク を利用して簡単に実装できるため、開発者にとっても利便性が高いです。 CIVILIOSでのOIDCの活用方法 内閣府 が作成した「スマートシティリファレンス アーキテクチャ 」では、データ連携基盤に接続する他のサービスやユーザーの認証管理をする機能を実現するための手法としてOIDCとOAuth2.0の併用が推奨されています。 CIVILIOSでは独自のIDプロバイダー機能(CIVILIOS-ID)を 保有 しており、この機能が冒頭のOIDCとOAuth2.0で認証/認可を行います。これにより、住民ポータル機能に市民がログインするためのIDや、オープンデータアップロード機能に 自治 体職員がログインするためのIDなどをこの機能で一元管理できます。 また、CIVILIOS-IDは認証/認可フローとしてOIDCフローにおけるIDプロバイダーへの窓口を API として公開しており、外部サービスとの連携にも対応しています。 CIVILIOS-IDの活用方法として シングルサインオン があります。 シングルサインオン （Single Sign -On、SSO）とは、ユーザーが一度の認証で複数のアプリケーションやサービスにアクセスできるようにする認証方式です。これにより、住民ポータル機能にログインするだけで住民ポータル機能と連携する外部サービスにも自動でログインできます。 また、 マイナン バーカードなどを利用して本人確認された認証情報を提供するデジタルIDなどのサービスとCIVILIOS-IDを紐づけることで、本人確認されたCIVILIOS-IDにできます。 さらにOIDCはデータ連携基盤であるCIVILIOSが他の外部サービスやデータ連携基盤とデータ連携する際にも活躍します。CIVILIOSは外部サービスに対してOIDCフローを通してアクセス トーク ンを渡します。外部サービスはこのアクセス トーク ンを用いることで、CIVILIOS内のデータやCIVILIOSと連携する他の外部サービスからデータを受け取ることができます。CIVILIOSはこのアクセス トーク ンを用いることで、外部サービス同士の連携やCIVILIOS内の機能へのアクセス、ユーザーがデータ連携に同意（オプトイン）しているかを確認して、データ連携を制御しています。 さいごに 本記事では、弊社の都市OS「CIVILIOS」における OpenID Connect（OIDC）の活用方法についてご紹介しました。CIVILIOSは、住民や 自治 体にとって利便性とセキュリティを両立させたデータ連携基盤を提供することで、スマートシティの実現を支援します。 OIDCを活用することで、住民は一度のログインで複数のサービスにアクセスでき、 自治 体は効率的にデータを管理・共有することが可能になります。また、CIVILIOS-IDを通じて、外部サービスとの連携もスムーズに行えるため、より多くのサービスを統合的に利用できます。 CIVILIOSはOIDCフローを通じて外部サービスにアクセス トーク ンを提供し、外部サービスはCIVILIOS内のデータや他の連携サービスからデータを受け取ることができます。これにより、セキュアなデータ連携と住民の同意（オプトイン）に基づいたデータ共有が可能になります。 今後もCIVILIOSは新しい機能を追加し、より多くの 自治 体に導入されることを目指しています。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @taguchi.kazutoshi 、レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）