はじめまして。クロスイノベーション本部、新卒1年目の大岡叡です。 現在、技術職に配属された同期6名とともに7月から9月の3か月間にわたるシステム開発研修に取り組んでいます。研修では、運営側が定めた必須機能に加えてチームで考えた追加機能を自由に実装することが認められています。 私のチームではある追加機能を実装することを決定し、その中でテキストの感情分析を取り入れることにしました。 開発したシステムは AWS ECS on Fargate にデプロイすることが決まっており、また私が学生時代からAWSの資格勉強をしていたことから、テキストの感情分析には Amazon Comprehend を利用することにしました。それにあたり、Amazon Comprehendを調査し実際にどのように使うのか検証しました。 本記事では、Amazon Comprehendを調べてみて・触ってみて学んだことをまとめています。 同じように初めてAmazon Comprehendを触る方のヒントになればと思います。 Amazon Comprehendの概要 概要 感情分析について DetectSentiment API BatchDetectSentiment API 感情分析APIの料金 具体的な料金例 シーケンス図 入力したテキストを感情分析させる簡単な検証 単一テキスト分析 複数テキスト分析 具体的なユースケースを想定した検証 まとめ 参考文献 Amazon Comprehendの概要 概要 Amazon ComprehendについてAWS公式サイトでは以下のように説明しています。要するに、Amazon Comprehendはテキストを様々な観点から分析してくれるツールです。 Amazon Comprehend は、機械学習 (ML) を使用してテキストから洞察を見つける自然言語処理 (NLP) サービスです。Amazon Comprehend は、Custom Entity Recognition、カスタム分類、キーフレーズ抽出、感情分析、エンティティ認識などの API を使用することにより、お使いのアプリケーションに NLP を簡単に統合できます。Amazon Comprehend API をお使いのアプリケーションに読み込むだけで、ソースとなるドキュメントやテキストの場所がわかります。API は、エンティティ、キーフレーズ、感情、言語を、アプリケーションで使用できる JSON 形式で出力します。 （ AWS公式サイト より引用） 感情分析について Amazon Comprehend の感情分析は、テキストがどのような感情を持っているのかを分類して返してくれる機能です。判定される感情は主に以下の4種類です。 POSITIVE （ポジティブな内容） NEGATIVE （ネガティブな内容） NEUTRAL （中立的な内容） MIXED （ポジティブ・ネガティブが混在） APIにテキストを送信すると単に感情ラベルを返すだけでなく、それぞれの感情にどれくらいの確信度があるかをスコア（0.0～1.0）で返してくれます。 利用できるAPIは "DetectSentiment"、"BatchDetectSentiment"、"StartSentimentDetectionJob"の3種類です。本記事では、"DetectSentiment"と"BatchDetectSentiment"を紹介します。（"StartSentimentDetectionJob"はS3上のテキストデータを対象に分析を行うAPIですが、研修で私のチームが構築しているシステムではテキストデータをS3に配置しないため説明を割愛いたします） DetectSentiment API 1件のテキストを対象に感情を判定するAPIです。 リクエスト例 { " Text ": " 今日はとても良い気分です ", " LanguageCode ": " ja " } レスポンス例 { " Sentiment ": " POSITIVE ", " SentimentScore ": { " Positive ": 0.999679684638977 , " Negative ": 8.19311972009018e-05 , " Neutral ": 0.0002277959865750745 , " Mixed ": 1.0496267350390553e-05 } } BatchDetectSentiment API 複数件（ 最大25件 ）のテキストをまとめて感情判定できるAPIです。 リクエスト例 { " TextList ": [ " 今日は楽しい ", " 明日は不安だ " ] , " LanguageCode ": " ja " } レスポンス例 { " ResultList ": [ { " Index ": 0 , " Sentiment ": " POSITIVE ", " SentimentScore ": { " Positive ": 0.9967367053031921 , " Negative ": 7.083657692419365e-05 , " Neutral ": 0.0030982368625700474 , " Mixed ": 9.416837565368041e-05 } } , { " Index ": 1 , " Sentiment ": " NEGATIVE ", " SentimentScore ": { " Positive ": 0.0007383294287137687 , " Negative ": 0.9037773013114929 , " Neutral ": 0.09547645598649979 , " Mixed ": 7.853302122384775e-06 } } ] , " ErrorList ": [] } 感情分析APIの料金 Amazon Comprehend の料金は、処理するテキスト量に応じた従量課金になっています。東京リージョンでの感情分析に関する料金は以下のとおりです（2025年9月2日時点）。 0.0001 USD / 1 単位 （100文字ごと） 日本語テキストを含む多言語に対応 各リクエストにつき3単位 （300 文字）の最低料金が発生します。 具体的な料金例 1件あたりの料金 テキスト長 課金単位数 料金 100文字 3単位（最低料金適用） 0.0003 USD 300文字 3単位 0.0003 USD 500文字 5単位 0.0005 USD 1,000文字 10単位 0.001 USD ※ 300文字以下のテキストは最低料金（3単位 = 0.0003 USD）が適用されます。 月間利用量ごとの料金目安（500文字/件の場合） 件数 料金 1,000件/月 0.5 USD（約75円） 10,000件/月 5 USD（約750円） 100,000件/月 50 USD（約7,500円） ※ 1 USD = 150円で換算 シーケンス図 感情分析を検証するために、以下のシーケンス図に基づいたシステムを実装しました。私のチームで考えた追加機能では複数のテキストをまとめて分析するため、Amazon ComprehendのBatchDetectSentiment APIを使用しました。また、研修でNext.js と Spring Bootを用いた開発を行っているため、今回も同様の技術スタックを採用しています。 次のセクションから、このシーケンス図に基づいたシステムを用いて行った検証について説明します。今回は検証であるため、Next.jsとSpring Bootはlocalhostでホストしました。 入力したテキストを感情分析させる簡単な検証 このセクションでは入力したテキストを感情分析させる簡単な検証について説明します。以下のような画面で検証を行いました。 テキストボックスにテキストを入れ、分析するボタンを押下すると分析結果が表示されます。 単一テキスト分析 まず、1つのテキストを分析するケースを試してみました。 「今日は疲れたが、色々楽しいことがあった一日だった。」という文は、「疲れた」という NEGATIVE な要素と「楽しい」という POSITIVE な要素が混ざっているため、MIXED と判定されました。期待通りの結果となったため、正しく動作していると考えられます。 複数テキスト分析 続いて、複数のテキストを分析するケースを試してみました。 単一テキストと同様に問題なく分析してくれました。 補足 「かんぱーい！」はポジティブに判定されるのでは？と思い、Amazon Comprehend のレスポンスを確認したところ、POSITIVE 約30%、NEGATIVE 約7%、NEUTRAL約62%という結果でした。 確かに「かんぱーい！」と発していても、もし気が進まない飲み会だったらネガティブな感情も含まれますよね。 C:\Users\torut>aws comprehend detect-sentiment --region ap-northeast-1 --language-code "ja" --text "かんぱーい！" { "Sentiment": "NEUTRAL", "SentimentScore": { "Positive": 0.3049440085887909, "Negative": 0.07437098026275635, "Neutral": 0.6194847822189331, "Mixed": 0.0012001828290522099 } } 具体的なユースケースを想定した検証 最後に、具体的なユースケースを想定し、アンケートの回答内容の感情分析を一括で行う検証を行いました。 結果は以下のようになりました。感情分析の結果も妥当であると感じました。 まとめ 今回、Amazon Comprehend を調査・検証してみて、特に印象に残ったのは 料金の安さ と バッチ処理の上限件数 です。 料金については、100文字単位で課金される仕組みですが、実際に計算してみると小規模な分析であればほとんどコストを気にせずに利用できることが分かりました。 一方で、BatchDetectSentiment API のリクエスト上限が1回あたり最大25件である点には注意が必要だと感じました。例えば 100 件を分析する場合、4 回に分けてリクエストを送る必要があります。実運用を考える際には、この制約を踏まえて処理設計を行う必要があると学びました。 そして、検証を通じて、Amazon Comprehendを利用するイメージがついたので、本検証を基に研修で開発しているシステムへの導入を進めていきたいと思います。 参考文献 https://aws.amazon.com/jp/comprehend/features/ https://aws.amazon.com/jp/comprehend/pricing/ https://docs.aws.amazon.com/comprehend/latest/dg/how-sentiment.html https://docs.aws.amazon.com/comprehend/latest/APIReference/API_DetectSentiment.html https://docs.aws.amazon.com/comprehend/latest/APIReference/API_BatchDetectSentiment.html https://docs.aws.amazon.com/comprehend/latest/APIReference/API_StartSentimentDetectionJob.html 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @ooka.toru レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

こんにちは。クロス イノベーション 本部 クラウド イノベーション センターの柴田です。本記事では Claude Code の画面に今月の利用料を表示する方法をご紹介します。 動機 利用する機能・ツール 実行環境 ステータスライン ccusage 設定方法 1. ステータスラインの表示内容を出力するプログラムを実装する 2. Claude Code の設定ファイルを更新する 実行結果 おわりに 参考資料 動機 私は Claude Code を Amazon Bedrock 経由で利用しています。 Amazon Bedrock は従量課金なのでうっかり Claude Code を使いすぎて利用料が高額にならないように気をつけなければなりません。そこでその対策として Claude Code の画面に今月の利用料を表示する ことにしました。 利用する機能・ツール 実行環境 本記事の実行環境は以下のとおりです。 Ubuntu 24.04 @anthropic-ai/claude-code@1.0.98 ccusage@16.2.0 ステータスライン Claude Code には画面下部にユーザー独自のステータスラインを表示する機能があります。今回はこの機能を使って Claude Code の画面に利用料情報を表示します。 ccusage ccusage は Claude Code の使用状況を分析するための CLI ツールです。今回はこの ccusage を使って Claude Code の今月の利用料を計算します。 1 なお ccusage にはステータスライン用の内容を出力する ccusage statusline コマンドがありますが、今月の利用料の表示をサポートしていないため今回は利用しません。 設定方法 1. ステータスラインの表示内容を出力するプログラムを実装する ステータスラインの表示内容を出力するプログラムを実装します。今回は以下の シェルスクリプト を ~/.claude/statusline.sh に保存します。 #!/bin/bash echo "💰 \$$(npx ccusage@16.2.0 monthly --json --offline --order desc | jq -r '.monthly[0].totalCost * 100 | round / 100') monthly" この シェルスクリプト では以下の処理を行っています。 ccusage monthly で月次の利用料を計算します。頻繁に実行されることを考慮してモデルの価格データは API ではなくキャッシュから取得します。 jq で今月の利用料のみを取得します。また利用料を小数第二位で四捨五入します。 結果を標準出力へ出力します。 chmod で先ほどの シェルスクリプト に実行権限を付与します。 chmod +x ~/.claude/statusline.sh 2. Claude Code の設定ファイルを更新する Claude Code の設定ファイル（ユーザー設定なら ~/.claude/settings.json ）の .statusLine.command に先ほど実装したプログラムのパスを指定します。 { " statusLine ": { " type ": " command ", " command ": " ~/.claude/statusline.sh " } } 設定は以上で完了です。 実行結果 実際に Claude Code の画面に今月の利用料が表示されるか確認してみましょう。適当なプロジェクトで Claude Code を起動します。すると画面の下部に今月の利用料が表示されていることを確認できます。 おわりに 本記事では Claude Code の画面に今月の利用料を表示する方法をご紹介しました。ステータスラインの表示内容はカスタマイズが可能です。利用料以外にも表示したい情報があれば追加してみてください。最後までお読みいただき、ありがとうございました。 参考資料 Status line configuration - Anthropic https://github.com/ryoppippi/ccusage 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @shibata.takao レビュー： @takami.yusuke （ Shodo で執筆されました ） ccusage は Claude Code が出力した トーク ン数やコスト情報から推定利用料を算出します。 Amazon Bedrock の実際の利用料のデータを取得しているわけではありません。本記事の方法で表示される利用料は目安として捉えてください。 ccusage のコスト計算の仕組みは Cost Modes | ccusage をご覧ください。 ↩

はじめに bunのインストール 作業環境の作成 Prettierのインストール Remarkのインストール パーザのセットアップ RemarkとPrettierの整合性を取る Remarkの一部としてPrettierを動かす Linterのセットアップ ドキュメントのリンク切れを検証する Linter用の設定ファイルを外部化する まとめ はじめに みなさんこんにちは、XI本部エンジニアリングオフィスの佐藤太一です。 Amazon のKiroが話題になったあたりから、AIに Markdown で仕様書を書いてもらうことで成果物の品質や作業品質を高める取り組みが注目されていますね。 Amazon のKiroだけでなく、 GitHub の Spec Kit 、 Claude Code Spec Workflow や Claude Code Spec など様々な活動が公開されています。 このエントリでは、そういった活動の中で少し見過ごされがちな Markdown ファイルそのものの品質を底上げするための取り組みを紹介します。 具体的には、RemarkとPrettierを組み合わせて Markdown ファイルが所定のルールに沿った記述がされているか自動的に保証する方法を説明します。 bunのインストール 今回利用するツールは JavaScript やTypeScriptで記述されています。 これらのツールは、継続的に繰り返し実行するため、少しでも高速に動作することが望ましいので、今回はbunを使って実行します。 Windows 環境であれば以下のコマンドでインストールできます。 powershell -c "irm bun.sh/install.ps1 | iex" Linux や Mac 環境なら以下のコマンドでインストールできます。 curl -fsSL https://bun.sh/install | bash bunは高速に動作するうえに特別な設定をせずにTypeScriptを直接実行できるので、私は日常的な スクリプト もTypeScriptで書いています。 作業環境の作成 今回は筆者の作業環境が Windows なので、それを前提に環境構築を行います。 プラットフォーム依存性のある話は全体としてほぼ存在しませんので、 Linux や Mac を使っている方は適宜読み替えてください。 作業用の ディレクト リとして、 C:/dev/md-tutorial に新しい ディレクト リを作成しました。 今後は、この ディレクト リ内で作業しているものと考えてください。 この ディレクト リに、 bunfig.toml というファイルを以下の内容で作成します。 [install] exact = true これによって、bunでインストールするツールのバージョンが常に固定されたものになります。 Prettierのインストール Prettierは、htmlや JavaScript 、TypeScriptなど最近のフロントエンド開発で使われているテキストファイルのフォーマットを自動的に行う 意見の強い フォーマッタです。 私自身は、全ての ソースコード はフォーマットをすべきであると考えています。 ただし、一貫性さえあればフォーマットのルールについてはあまりこだわりがないので、Prettierを常用しています。 以下のコマンドを実行して、Prettierをbunでインストールしましょう。 bun add prettier 以下のように package.json が作成されます。 { " dependencies ": { " prettier ": " 3.6.2 " } } これにbunからPrettierを実行するためのコマンドを追加します。 { " dependencies ": { " prettier ": " 3.6.2 " } , " scripts ": { " lint:prettier ": " prettier --check docs/ ", " format:prettier ": " prettier --write docs/ " } } 今回はPrettierで検査対象にするファイルは docs/ ディレクト リに格納されるものとしてタスクを定義しました。 では、 docs/ ディレクト リに README.md を以下の内容で作成しましょう。 # Title Long Long Long Long Long Long Long Long Long Long Long Long Long Long Long Long Long Long Body Text Prettierの動作確認をしたいので、少し奇妙なファイルです。 タイトルの後ろに無意味な半角スペースがあったり、空行のみの行がスペースでインデントされていたりします。 この状態でPrettierを実行してみましょう。以下のコマンドを実行します。 bun lint:prettier 以下のように出力されました。 ファイルに問題があるようですね。しかし、今回の問題は自動的に対処できるものです。 では、以下のコマンドを実行しましょう。 bun format:prettier 実行結果は以下のように出力されます。 自動的な折り返しはされないようですね。しかし、余分な半角スペースは全て除去されています。 Prettierは基本的に設定の調整が不要なのですが、いくつか私の趣味に合わない部分があるので、そこだけは変えましょう。具体的には、タブと一行の最大幅と改行コードです。 タブは半角スペース2つに変換します。一行の幅はデフォルトの80文字から120文字に増やしましょう。改行コードはLFのみに固定します。 { " dependencies ": { " prettier ": " 3.6.2 " } , " prettier ": { " tabWidth ": 2 , " printWidth ": 120 , " endOfLine ": " lf " } , " scripts ": { " lint:prettier ": " prettier --check docs/ ", " format:prettier ": " prettier --write docs/ " } } あわせて、 .gitattributes ファイルを以下の内容で作成します。 text=auto eol=lf Remarkのインストール Remarkは JavaScript で実装された Markdown の処理ツールです。たくさんの プラグイン があり、処理ツールとしての機能を調節できるようになっています。 また、パーズしてASTになった Markdown をファイルに書き出せるような形式に永続化する機能もあります。 パーザのセットアップ まずは、Remarkのパーザ部分をセットアップしてみましょう。以下のコマンドで3つのモジュールをインストールします。 bun add remark-cli remark-frontmatter remark-gfm あわせて、bunから呼び出せるようにコマンドを追加します。 { " dependencies ": { " prettier ": " 3.6.2 ", " remark-cli ": " 12.0.1 ", " remark-frontmatter ": " 5.0.0 ", " remark-gfm ": " 4.0.1 " } , " prettier ": { " tabWidth ": 2 , " printWidth ": 120 , " endOfLine ": " lf " } , " scripts ": { " lint:md ": " remark --frail docs/ ", " lint:prettier ": " prettier --check docs/ ", " format:md ": " remark docs/ --frail --output ", " format:prettier ": " prettier --write docs/ " } } おっと、Remarkが追加したモジュールを動作するように構成していませんでした。 { " dependencies ": { " prettier ": " 3.6.2 ", " remark-cli ": " 12.0.1 ", " remark-frontmatter ": " 5.0.0 ", " remark-gfm ": " 4.0.1 " } , " prettier ": { " tabWidth ": 2 , " printWidth ": 120 , " endOfLine ": " lf " } , " remarkConfig ": { " plugins ": [ " remark-frontmatter ", " remark-gfm " ] } , " scripts ": { " lint:md ": " remark --frail docs/ ", " lint:prettier ": " prettier --check docs/ ", " format:md ": " remark docs/ --frail --output ", " format:prettier ": " prettier --write docs/ " } } remarkConfigにpluginsというプロパティがあるので、そこに追加したい プラグイン のモジュール名を列挙しています。今回は remark-frontmatter と remark-gfm ですね。 動作を確認していきましょう。とはいえ、既に用意した docs/README.md では何も起きないので新しいファイルを追加します。 docs/list.md というファイルを以下の内容で保存します。 --- author: taichi category: - example - sample --- # Title _foo bar baz_ ## Sub Title - [ ] one - [ ] two - [ ] three foo bar baz 1. first 1. second 1. third ---- frontmatterという YAML で メタデータ を付けた Markdown ですね。Listの部分では、 GitHub 固有の チェックボックス 記法を使っています。 Remarkの動作を確認してみましょう。以下のコマンドを実行します。 bun lint:md 特にエラーなく処理が終了するでしょう。 次は、フォーマットタスクを実行しましょう。以下のコマンドです。 bun format:md docs/list.md を開きなおしてみてください。興味深い変化が起きているはずです。 --- author: taichi category: - example - sample --- # Title *foo bar baz* ## Sub Title * [ ] one * [ ] two * [ ] three foo bar baz 1. first 2. second 3. third *** frontmatter部分に変化はありません。 次のTitleより下のイタリック体になっていた記号が変化しています。フォーマット前は _foo bar baz_ とアンダースコア記号を使っていましたが、フォーマット後は *foo bar baz* と アスタリスク が使われています。 リスト記法の - も * に変化しています。 同様に区切り線として、ハイフンを使っていたので ---- でしたが、フォーマット後は **** になっています。 最後の順序付きリストは、数字が昇順に調整されています。 これがRemarkに内蔵されている remark-stringify の正常な動作です。 Markdown をパーズしてASTにした後、メモリ上の表現を一定のルールで文字列に永続化するわけです。 このままでは、少し都合が悪いので調整しましょう。remarkConfigに settings プロパティを追加します。 { " dependencies ": { " prettier ": " 3.6.2 ", " remark-cli ": " 12.0.1 ", " remark-frontmatter ": " 5.0.0 ", " remark-gfm ": " 4.0.1 " } , " prettier ": { " tabWidth ": 2 , " printWidth ": 120 , " endOfLine ": " lf " } , " remarkConfig ": { " settings ": { " bullet ": " - ", " emphasis ": " _ ", " rule ": " - " } , " plugins ": [ " remark-frontmatter ", " remark-gfm " ] } , " scripts ": { " lint:md ": " remark --frail docs/ ", " lint:prettier ": " prettier --check docs/ ", " format:md ": " remark docs/ --frail --output ", " format:prettier ": " prettier --write docs/ " } } ここでは、 リストに使う記号として - 斜体やボールドなどを強調する際に使う記号として _ 区切り線として使う記号として - を設定しています。 では、もう一度フォーマッタを動かしてみましょう。 bun format:md 処理は成功し以下のように設定に基づいた表現になっているはずです。順序付きリストだけが昇順のままですね。 --- author : taichi category : - example - sample --- # Title _foo bar baz_ ## Sub Title - [ ] one - [ ] two - [ ] three foo bar baz 1. first 2. second 3. third --- これで分かったように、Remarkを Markdown のフォーマッタとして使う場合には、remarkConfigオブジェクトのsettingsプロパティを調整します。その設定項目は、 remark-stringify#options に記載されています。 RemarkとPrettierの整合性を取る Prettierはテキストファイルのフォーマットを整えるツールですが、実はRemarkのLintルールの中には、Prettierの動作と矛盾するものや重複するものが含まれています。 Prettierとうまく組み合わさらないものは、あらかじめ無効にしてしまいましょう。そのためのモジュールを以下のコマンドでインストールします。 bun add remark-preset-prettier モジュールを追加したら、そのモジュール名を プラグイン として追加します。以下のようになるでしょう。 { " dependencies ": { " prettier ": " 3.6.2 ", " remark-cli ": " 12.0.1 ", " remark-frontmatter ": " 5.0.0 ", " remark-gfm ": " 4.0.1 ", " remark-preset-prettier ": " 2.0.2 " } , " prettier ": { " tabWidth ": 2 , " printWidth ": 120 , " endOfLine ": " lf " } , " remarkConfig ": { " settings ": { " bullet ": " - ", " emphasis ": " _ ", " rule ": " - " } , " plugins ": [ " remark-frontmatter ", " remark-gfm ", " remark-preset-prettier " ] } , " scripts ": { " lint:md ": " remark --frail docs/ ", " lint:prettier ": " prettier --check docs/ ", " format:md ": " remark docs/ --frail --output ", " format:prettier ": " prettier --write docs/ " } } 次はフォーマットしがいのあるコンテンツを用意しましょう。docs/table.md として以下のようなファイルを作成します。 # Table | Column1 | Label | Description | | ----- | ----- | ----- | | val | aaaaaaa | Lorem ipsum dolor sit amet, consectetur adipiscing elit | | valval | aa | sed do eiusmod tempor incididunt ut labore | | foo | d | Duis aute irure dolor in reprehenderit in voluptate | | xxxxxxx | | deserunt mollit anim id est laborum | Prettierでフォーマットするコマンドは以下のとおりです。 bun format:prettier コマンドが正常に終了したら、どのようにフォーマットされるか確認してみましょう。 # Table | Column1 | Label | Description | | ------- | ------- | ------------------------------------------------------- | | val | aaaaaaa | Lorem ipsum dolor sit amet, consectetur adipiscing elit | | valval | aa | sed do eiusmod tempor incididunt ut labore | | foo | d | Duis aute irure dolor in reprehenderit in voluptate | | xxxxxxx | | deserunt mollit anim id est laborum | フォーマットする前のテーブルは正直言ってHTMLなりエディタの プレビュー機能 なりを使わなければ内容が把握できないものでしたが、Prettierのフォーマットによりテキスト表現だけでも読めるようになりましたね。 Remarkの一部としてPrettierを動かす RemarkによるフォーマットとPrettierによるフォーマットを毎回動かすのはやや面倒ですし、何かの拍子に抜けてしまいそうです。 というわけで、Remarkの処理の最後にPrettierを動かすための プラグイン を導入しましょう。 bun add unified-prettier これまで通り、pluginsに追加ですね。出力用の プラグイン なので remark-preset-prettier よりも後ろに配置します。 { "dependencies": { "prettier": "3.6.2", "remark-cli": "12.0.1", "remark-frontmatter": "5.0.0", "remark-gfm": "4.0.1", "remark-preset-prettier": "2.0.2", "unified-prettier": "2.0.1" }, "prettier": { "tabWidth": 2, "printWidth": 120, "endOfLine": "lf" }, "remarkConfig": { "settings": { "bullet": "-", "emphasis": "_", "rule": "-" }, "plugins": [ "remark-frontmatter", "remark-gfm", "remark-preset-prettier", "unified-prettier" ] }, "scripts": { "lint:md": "remark --frail docs/", "lint:prettier": "prettier --check docs/", "format": "remark docs/ --frail --output" } } PrettierとRemarkによるフォーマットは統合されたので、コマンド名はシンプルな format に変更しています。 Linterのセットアップ それでは、いよいよLinter機能をRemarkに追加しましょう。 Remarkが公式で提供しているLinterは、 remark-lint/packages に並んでいるのですが、この細かいルールを一つずつ選定していくのは面倒です。複数のルールを束にしたプリセットを公式から提供されていますので、それを使いましょう。 remark-preset-lint-recommended Markdown を使ううえで基本的なルールの集合です。今回はこれを採用します。 remark-preset-lint-consistent ドキュメント内で記法が一貫するように強制するルールの集合です。 それぞれの記法において、ファイル内で最初に登場した記法が一貫して使われているかどうかを検証できます。 今回は新規のプロジェクトを前提にしますので不採用です。 remark-preset-lint-markdown-style-guide Markdown Style Guide という極めて強い意見の Markdown に関するスタイルガイドを採用したルールです。 今回はそれほど多くのドキュメントがあるわけではないので不採用です。 まずは、モジュールをインストールします。 bun add remark-preset-lint-recommended モジュールをインストールしたら プラグイン として追加します。 { " dependencies ": { " prettier ": " 3.6.2 ", " remark-cli ": " 12.0.1 ", " remark-frontmatter ": " 5.0.0 ", " remark-gfm ": " 4.0.1 ", " remark-preset-lint-recommended ": " 7.0.1 ", " remark-preset-prettier ": " 2.0.2 ", " unified-prettier ": " 2.0.1 " } , " prettier ": { " tabWidth ": 2 , " printWidth ": 120 , " endOfLine ": " lf " } , " remarkConfig ": { " settings ": { " bullet ": " - ", " emphasis ": " _ ", " rule ": " - " } , " plugins ": [ " remark-frontmatter ", " remark-gfm ", " remark-preset-lint-recommended ", " remark-preset-prettier ", " unified-prettier " ] } , " scripts ": { " lint:md ": " remark --frail docs/ ", " lint:prettier ": " prettier --check docs/ ", " format ": " remark docs/ --frail --output " } } Remarkの プラグイン システムは、配列の後ろ側になるほどルールとして優先されますので、今回追加するプリセットはちょうど中ほどに入るように追加します。 lintのルールを追加したのですから、エラーが発生するような Markdown を作りましょう。docs/link.md を以下の内容で作成します。 # Links https : //example.com リンク記法が使われずにリンクのようなものがテキストとして記述されていますので、これは警告されるはずです。 Linterを実行するコマンドは以下のとおりです。 bun lint : md 実行すると確かに警告が出力され、プロセスがエラーで終了します。 リンク記法を使うべきであるという警告が出力されていますね。これが自動的に改善されるかどうか確認してみましょう。 bun format Linterを実行したときと同じエラーが出力されていますね。 では、 Markdown ファイルはどうなっているのでしょうか。 # Links < https://example.com > リンクが <> でくくられていますね。自動修正は機能しているようです。ただ、AIを使った開発においては、この出力だとAIが標準出力されたメッセージを根拠に解決を試みます。 つまり、当該ファイルを開くものの実際には修正済みという状態になってしまいますので、一定の混乱が発生します。 通信した トーク ン量で課金されたり、制限される今のAI相手にはこういう無駄が起きないようにしなければなりません。 この問題に対応するために設定を調整してみましょう。pluginsプロパティにモジュールを列挙すると常に使われてしまうので、Linterを動かすときとフォーマッタを動かすときで使うモジュールを切り替える必要があります。 remarkコマンドの -u オプションを使うと個別にモジュールを指定できます。 { " dependencies ": { " prettier ": " 3.6.2 ", " remark-cli ": " 12.0.1 ", " remark-frontmatter ": " 5.0.0 ", " remark-gfm ": " 4.0.1 ", " remark-preset-lint-recommended ": " 7.0.1 ", " remark-preset-prettier ": " 2.0.2 ", " unified-prettier ": " 2.0.1 " } , " prettier ": { " tabWidth ": 2 , " printWidth ": 120 , " endOfLine ": " lf " } , " remarkConfig ": { " settings ": { " bullet ": " - ", " emphasis ": " _ ", " rule ": " - " } , " plugins ": [ " remark-frontmatter ", " remark-gfm " ] } , " scripts ": { " lint:md ": " remark --frail docs/ -u remark-preset-lint-recommended -u remark-preset-prettier ", " lint:prettier ": " prettier --check docs/ ", " format ": " remark docs/ --frail --output -u remark-preset-prettier -u unified-prettier " } } この設定では、Linterとフォーマッタで共通して使う部分はremarkConfig以下に定義し、違う部分は各コマンドの引数として定義しています。 それでは、確認のため、補正済みのdocs/link.md を補正前に戻したうえで、Linterを動かしてみましょう。 エラーが出力されていますね。 では、フォーマッタを動かしてみましょう。 エラーや警告が出力されないので、プロセスは正常に終了します。 そして、 Markdown は自動補正されて正しくフォーマットされていますね。 # Links < https://example.com > ドキュメントのリンク切れを検証する 設計ドキュメントとして Markdown を使うということは、役割や責任範囲毎にファイルを分割していき、それらを ハイパーリンク で接続するという使い方が想定されます。 そうしたとき問題になるのが、ドキュメント間のリンク切れ問題です。ファイル名やファイルパスを変更することによって、リンク切れは頻繁に発生します。これをきちんとメンテナンスしていくのは、非常に面倒なタスクですよね。 そこで、Linterの一部としてリンク切れをチェックしエラーを標準出力することで、リンクのメンテナンスを生成AIに任せましょう。 Remarkにはリンク切れを検証する プラグイン がいくつかあるので、それらをまとめてインストールしましょう。 bun add remark-validate-links remark-lint-no-dead-urls remark-validate-links が同じ ディレクト リツリー内にあるファイルへのリンクを検証する プラグイン です。それに対して、 remark-lint-no-dead-urls はリンクとして記載されているURLにHTTPリク エス トを送信して機能しているか検証する プラグイン です。 これをLinter用のコマンドに組み込むとこうなります。 { " dependencies ": { " prettier ": " 3.6.2 ", " remark-cli ": " 12.0.1 ", " remark-frontmatter ": " 5.0.0 ", " remark-gfm ": " 4.0.1 ", " remark-lint-no-dead-urls ": " 2.0.1 ", " remark-preset-lint-recommended ": " 7.0.1 ", " remark-preset-prettier ": " 2.0.2 ", " remark-validate-links ": " 13.1.0 ", " unified-prettier ": " 2.0.1 " } , " prettier ": { " tabWidth ": 2 , " printWidth ": 120 , " endOfLine ": " lf " } , " remarkConfig ": { " settings ": { " bullet ": " - ", " emphasis ": " _ ", " rule ": " - " } , " plugins ": [ " remark-frontmatter ", " remark-gfm " ] } , " scripts ": { " lint:md ": " remark --frail docs/ -u remark-preset-lint-recommended -u remark-preset-prettier -u remark-validate-links=repository:false -u remark-lint-no-dead-urls=deadOrAliveOptions:{timeout:10000} ", " lint:prettier ": " prettier --check docs/ ", " format ": " remark docs/ --frail --output -u remark-preset-prettier -u unified-prettier " } } Linter用のコマンドが長くなり始めていますね。必要な所だけ抜粋して説明します。 内部リンクを検証する プラグイン の設定部分がこれです。 -u remark-validate-links=repository:false remarkコマンドのオプションとして、モジュール毎の設定を記述するには、モジュール名の最後に = を付けたうえで、最外周の {} がないJSON5を記述します。 remark-validate-linksは、検証対象がgit リポジトリ でかつoriginが設定されていることを前提に動作するので、その機能を無効化するために repository:false を設定しています。 普段ならこの設定は不要でしょう。 外部リンクを検証する プラグイン の設定部分がこれです。 -u remark-lint-no-dead-urls=deadOrAliveOptions:{timeout:10000} remark-lint-no-dead-urls は dead-or-alive というライブラリを内部的に使っています。その タイムアウト オプションをここでは設定しています。 これらの プラグイン が機能するか確認するために、先ほどの docs/links.md に手を加えて内部リンクと外部リンクを追加してみましょう。 # Links < https://example.com > ## Internal Links * [ Exists ]( #Links ) * [ NotExists ]( #likns ) ## External Links * [ External Example ]( https://example.com ) * [ NotExists External ]( https://example.com/fail ) では、リンク切れを検証してみましょう。以下のコマンドを実行します。 bun lint:md 実行結果はエラー終了になります。 タイポしているページ内のリンクと、存在しない外部ページに対するリンクが警告やエラーとして検出されていますね。 Linter用の設定ファイルを外部化する CLI オプションとしてJSON5を記述するというのは、分かり辛いので設定ファイルを外部化しましょう。 それではフォーマッタの設定から分離します。設定ファイルを config/remark-format.json に作成してください。 { " settings ": { " bullet ": " - ", " emphasis ": " _ ", " rule ": " - " } , " plugins ": [ " remark-frontmatter ", " remark-gfm ", " remark-preset-prettier ", " unified-prettier " ] } フォーマッタの設定はパーザとシ リアラ イザだけなのでシンプルですね。 次にLinterの設定ファイルを分離します。 config/remark-lint.json に作成します。 { " settings ": { " bullet ": " - ", " emphasis ": " _ ", " rule ": " - " } , " plugins ": [ " remark-frontmatter ", " remark-gfm ", " remark-preset-lint-recommended ", " remark-preset-prettier ", [ " remark-validate-links ", { " repository ": false } ] , [ " remark-lint-no-dead-urls ", { " deadOrAliveOptions ": { " timeout ": 10000 } } ] ] } このエントリではやりませんが、Linter側の設定はまだかなり調整の余地があるでしょう。 最後にpackage. json から不要になった設定を削除して、コマンドを調整します。 { " dependencies ": { " prettier ": " 3.6.2 ", " remark-cli ": " 12.0.1 ", " remark-frontmatter ": " 5.0.0 ", " remark-gfm ": " 4.0.1 ", " remark-lint-no-dead-urls ": " 2.0.1 ", " remark-preset-lint-recommended ": " 7.0.1 ", " remark-preset-prettier ": " 2.0.2 ", " remark-validate-links ": " 13.1.0 ", " unified-prettier ": " 2.0.1 " } , " prettier ": { " tabWidth ": 2 , " printWidth ": 120 , " endOfLine ": " lf " } , " scripts ": { " format ": " remark docs/ --frail --output -r config/remark-format.json ", " lint ": " remark --frail docs/ -r config/remark-lint.json " } } Prettierを直接利用するケースは基本的にありませんので、あわせてコマンドをシンプルにしておきました。 まとめ 今回のエントリでは、順を追ってPrettierの導入からRemarkによるフォーマット、その後Linterを導入し、最後は設定ファイルを切り出して調整しやすい状態にしました。 ここで紹介した手法を使えば、生成AIが出力する大量のテキストファイルのファイルフォーマットや構成を一定の水準に保てるようになります。 生成AIは出力した文章の中身について理解しておらず、それっぽいものを出力するのみですが、こうやって自動的に対処できる部分については、AIに対処してもらうことで私たちはより意味のあるレビューを行えるようになるはずです。 このエントリを読んだ皆さんが、より高品質なドキュメントを元にソフトウェア開発が実施できるようになることを願っています。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @sato.taichi レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

こんにちは。グループ経営ソリューション事業部 グループ経営 コンサルティング 第2ユニット サイクロス製品開発部の座間です。 この記事は、 MCP が提供しているElicitationという機能が公式TypeScript SDK で使用できるようになっていたので、キャッチアップがてら少し触ってみたという内容でお送りします。 Elicitationについて 定義 公式ドキュメント ではElicitationについて以下のように記載されています。 The Model Context Protocol ( MCP ) provides a standardized way for servers to request additional information from users through the client during interactions. This flow allows clients to maintain control over user interactions and data sharing while enabling servers to gather necessary information dynamically. つまり、Elicitationは「 MCP Serverからユーザーに追加の情報を要求できる標準化された方法」と言えそうです。 Elicitationは公式にはdraft段階ですが、実装側ではTypeScript SDK 、 MCP ホスト側では GitHub Copilotなどがすでに対応しています。 使い道 MCP公式TypeScript SDKのREADME 記載の実装例では、おおまかに以下のような流れの中でElicitationを使用しています。 ユーザーが日時を指定してレストランを予約するようエージェントに指示する エージェントは指定された日時とレストラン名で予約を試みるが、すでに予約が埋まってしまっている エージェントはElicitation機能を利用して、ユーザーに別の日時を選択することを求める エージェントはユーザーから受け取った新しい日時を基にレストランを予約する 上記フローはユーザーが見える範囲にフォーカスして記述しています。 実際にElicitationを使う判断をしているのは MCP Server Toolです。 「Toolの実行途中に追加の情報を取得できる」という特性を考えると、上記以外にも以下のようなことに使えそうですね。 Toolが途中まで処理した結果をユーザーに提示し承認を求める。OKなら処理を進め、NGなら実行をキャンセルする。 Tool呼び出し時にエージェントが推論で補完しきれなかった引数をユーザーが追加で入力するように求める。 MCP 公式TypeScript SDK で実装してみた まずはElicitationがどのようなものなのかを感じ取るために、挨拶をしてくれるだけの簡単な MCP Serverを実装してみます。 環境 Node.js 18.20.8 @modelcontextprotocol/ sdk 1.17.3 MCP Serverを利用するホストとしては、 GitHub Copilotを VS Code から使用します。 MCP Serverの実装 最初に、ただテキストを返すだけの MCP Serverを実装します。詳細な実装方法は 公式のクイックスタート 等、すばらしい記事がたくさんあるので割愛します。 import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js" ; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js" ; const server = new McpServer( { name : "elicitation-tutorial" , version : "1.0.0" , } ); server.tool( "Greet" , "Say Hello to you" , {} , async () => { return { content : [ { type : "text" , text : `こんにちは` } ] } ; } ); async function main () { const transport = new StdioServerTransport(); await server.connect(transport); console .error( "MCP Server running on stdio" ); } main(). catch (( error ) => { console .error( "Fatal error in main():" , error); process .exit( 1 ); } ); Elicitation機能の追加 上記で作成した MCP ServerにElicitation機能を追加してみましょう。TypeScript SDK では elicitInput というメソッドを使用します。 let yourName: string | undefined ; const result = await server.server.elicitInput( { message : "あなたについて教えてください" , requestedSchema : { type : "object" , properties : { yourName : { type : "string" , title : "氏名" , description : "あなたの名前を入力してください" } } , required : [ "yourName" ] } } ); if (result. action === "accept" && result.content && result.content.yourName) { yourName = String (result.content.yourName); } 少しだけ解説します。 elicitInput で指定する引数の構造は以下のとおりです。これ以外にも指定できる項目もあるので、詳細は MCPの公式ドキュメント などをご確認ください。 message : ユーザーに入力を求めるときに表示するテキスト requestedSchema : 期待するレスポンスの形式を定義する JSON スキーマ type : 期待するデータ型だが、基本的に構造化データを受け取りたいので object 固定 properties : ユーザーに入力を求めるプロパティ ${プロパティ名} : 上記の例では最初に定義した yourName を受け取りたいので yourName を指定 type : 期待するデータ型。 string number boolean から指定可能 title : タイトル description : プロパティについての説明 required : 入力を必須とするプロパティ名の配列 また、 elicitInput メソッドの戻り値には action 属性が含まれます。 action はユーザーの操作結果によって以下の3種類の値をとります。 accept : ユーザーが承認し、データを入力した decline : ユーザーが追加の入力を明示的に拒否した cancel : ダイアログを閉じる等でユーザーが明示的に選択せずに終了した Elicitationを組み込んだserver.toolの実装は以下のようになります。 server.tool( "Greet" , "Say Hello to you" , {} , async () => { let yourName: string | undefined ; const result = await server.server.elicitInput( { message : "あなたについて教えてください" , requestedSchema : { type : "object" , properties : { yourName : { type : "string" , title : "氏名" , description : "あなたの名前を入力してください" } } , required : [ "yourName" ] } } ); if (result. action === "accept" && result.content && result.content.yourName) { yourName = String (result.content.yourName); } return { content : [ { type : "text" , text : `こんにちは、 ${ yourName } さん` } ] } ; } ); これで、挨拶をしようとするとユーザーの名前を聞いてくるToolの完成です。早速使ってみましょう！ まずは GitHub Copilotに挨拶ツールを使わせます。すると message で定義したメッセージが表示され、名前を入力するよう求められます。 Respondボタンを押すと上部に入力ボックスが出てくるので、名前を入力します。 名前を渡すとToolの実行が再開します。無事入力した名前で挨拶してくれました。 このようにElicitationを利用すると、Toolの実行を中断して追加の情報を与えることができます。 試してみた：Elicitationを組み込んだ健康アドバイザーToolの実装 ここまででElicitationについてざっと理解できたので、ちょっとした遊びも兼ねて健康アド バイス を実施してくれるToolを実装してみました。 あらかじめ設定しておいた質問をエージェントが順々に投げかけ、集めた回答をもとに簡単な健康アド バイス を提供してくれます。 実演 「健康診断して」と伝えて開始します。基本情報を求められるので入力します。 最初は睡眠に関する質問です。 type: number を指定しているので、数値以外はエラーが出るようになっています。 properties で複数のプロパティを定義すると、Respondボタンは表示されずにそのまま次の質問に移ります。プロパティの中で enum を定義すると選択式にもできます。 続いて運動習慣に関する質問です。 type: boolean を使用するとtrue/falseで選択できます。 最後に朝食に関する質問です。 required に含めなかったプロパティは None No selection を選択してスキップすることもできます。 質問をすべて入力し終えるとToolが最後まで実行されます。健康アド バイス を実施する旨を記載したプロンプトを戻り値にしているため、Toolの実行結果を受け取ったエージェントが考えてアド バイス をしてくれます。 無事アド バイス をしてくれました！現在の実装では質問を固定していますが、質問自体も生成AIが考えられるようにしても面白そうですね。 実装 だいぶ長いですが参考として実装も載せておきます。基本的には最初に実装した elicitInput を少し変えながら連続して配置しています。 今回は action: accept のパターンしか処理を書いていませんが、実際は action: decline や action: cancel の場合の処理も書いてあげた方が良いです。ユーザーがRespondではなくCancelボタンを押した場合でもToolの実行は継続され、次のセクションの質問に移ってしまいます。 server.tool( "CheckHealth" , "いくつかの質問からユーザの健康状態の診断と改善アドバイスを実施します" , {} , async () => { let userName: string | undefined ; let age: number | undefined ; let sleepTime: number | undefined ; let sleepQuality: string | undefined ; let doesExerciseRegularly: boolean | undefined ; let hasBreakfastEveryday: boolean | undefined ; let breakfastMenu: string | undefined ; const userInfoResult = await server.server.elicitInput( { message : "まずは、あなた自身について教えてください" , requestedSchema : { type : "object" , properties : { name : { type : "string" , title : "氏名" , description : "あなたの名前を教えてください" } , age : { type : "number" , title : "年齢" , description : "あなたの年齢を教えてください" } } , required : [ "name" , "age" ] } } ); if (userInfoResult. action === "accept" && userInfoResult.content) { if (userInfoResult.content. name ) { userName = String (userInfoResult.content. name ); } if (userInfoResult.content.age) { age = Number (userInfoResult.content.age); } } const sleepInfoResult = await server.server.elicitInput( { message : ` ${ userName } さんの睡眠について教えてください` , requestedSchema : { type : "object" , properties : { question1 : { type : "number" , title : "睡眠時間" , description : "あなたの平均的な睡眠時間を教えてください" } , question2 : { type : "string" , title : "睡眠の質" , description : "最近よく眠れている実感はありますか？" , enum : [ "常にある" , "ある" , "あまりない" , "ない" ] } } , required : [ "question1" , "question2" ] } } ) if (sleepInfoResult. action === "accept" && sleepInfoResult.content) { if (sleepInfoResult.content.question1) { sleepTime = Number (sleepInfoResult.content.question1); } if (sleepInfoResult.content.question2) { sleepQuality = String (sleepInfoResult.content.question2); } } const exerciseInfoResult = await server.server.elicitInput( { message : ` ${ userName } さんの運動習慣について教えてください` , requestedSchema : { type : "object" , properties : { question3 : { type : "boolean" , title : "運動習慣" , description : "日常的に運動していますか？" } } , required : [ "question3" ] } } ) if (exerciseInfoResult. action === "accept" && exerciseInfoResult.content && exerciseInfoResult.content.question3 !== undefined ) { doesExerciseRegularly = Boolean (exerciseInfoResult.content.question3); } const breakfastInfoResult = await server.server.elicitInput( { message : ` ${ userName } さんの朝食事情について教えてください` , requestedSchema : { type : "object" , properties : { question4 : { type : "boolean" , title : "毎日食べているか" , description : "朝ごはんは毎日食べていますか？" } , question5 : { type : "string" , title : "朝食の内容" , description : "よく食べる朝ごはんのメニューを教えてください" } } , required : [ "question4" ] } } ) if (breakfastInfoResult. action === "accept" && breakfastInfoResult.content) { if (breakfastInfoResult.content.question4 !== undefined ) { hasBreakfastEveryday = Boolean (breakfastInfoResult.content.question4); } breakfastMenu = breakfastInfoResult.content.question5 ? String (breakfastInfoResult.content.question5) : "未回答" ; } const prompt = [ `以下の情報を基に ${ userName } さんの健康状態を判断し、適切なアドバイスをしてください。` , `・年齢： ${ age } 歳` , `・睡眠時間：平均 ${ sleepTime } 時間` , `・日頃から眠れているか： ${ sleepQuality } ` , `・日常的に運動しているか： ${ doesExerciseRegularly } ` , `・朝食を毎日食べているか： ${ hasBreakfastEveryday } ` , `・朝食の内容： ${ breakfastMenu } ` ] . join ( ' \n ' ); return { content : [ { type : "text" , text : String ( prompt ) } ] } ; } ); おわりに 本記事では、 MCP の機能の1つであるElicitationについて、簡単な実装例とともに解説しました。 「Toolの実行途中にユーザーが入力できるボックスを表示させる」という特性は様々な用途に使えそうですね。 MCP にはElicitation以外にもSamplingなど面白そうな機能がまだまだあるので、色々試していきたいです。 最後までお読みいただきありがとうございました！本記事が少しでも皆様のご参考になれば幸いです。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @zama.kazuki レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

こんにちは。 電通 総研ITの寺尾です。 今回は IntelliJ の リファクタリング 機能 の実装方法についてご紹介します。 前回はこちら： IntelliJプラグイン開発の始め方～コード補完編～ リファクタリング とは クラス名や変数名を変更した際、それを参照している別コードでも一緒にリネームしてくれる、パッケージ移動した際に変更後の状態に合わせてパッケージ名を変更してくれる機能を自然と使用している開発者は多いと思います。 プラグイン 開発では IntelliJ に拡張ポイントを実装し、任意の処理を リファクタリング に合わせて実行させることができるようになります。 実装前に知っておくこと 前回と同様に、本記事でもKotlinでの実装例を提示します。 Kotlinプロジェクトに関する内容は、アクション機能編の 実装前に知っておくこと をご参照ください。 実装 ゴール 今回は、DAO名を変更した際に対応する SQL ディレクト リ名をリネームする拡張ポイントの実装をします。 事前準備 IntelliJ プラットフォーム プラグイン の SDK では、特定の要素に専用の プロセッサー クラスが用意されています。 今回はクラス名のリネーム用クラス RenameJavaClassProcessor を使用して拡張ポイントを実装します。 まずは以下の準備から始めていきましょう。 RenameJavaClassProcessor のサブクラス プラグイン 設定登録 リファクタリング 機能は拡張ポイントとして登録します。 plugin.xml には、以下のように <renamePsiElementProcessor> タグを使って プロセッサー クラスを登録します。 IntelliJ の拡張ポイントとして登録するため、 <extensions defaultExtensionNs="com.intellij"> タグの中に記述します。 <renamePsiElementProcessor implementation = "org.domaframework.doma.intellij.refactoring.dao.DaoRenameProcessor" order = "first" /> プロセッサー クラスの実装 プロセッサー クラスでは、以下のオーバーライドメソッドを実装します。 canProcessElement ：リネーム時、 プロセッサー の実行条件を満たしているかを判定する renameElement ：リネーム前の要素情報とリネーム後の名称を受け取り任意の処理を実行 処理対象の判定 DAO名のリネーム以外で SQL ディレクト リ名が変更されないように、しっかり事前チェックをしておきます。 canProcessElement の中で、以下のように処理対象であるかを判定します。 getDaoClass() は、引数の要素がDAOが存在することを判定する独自のメソッドです。任意の処理で同様にチェックしてみてください。 override fun canProcessElement(element: PsiElement): Boolean = super .canProcessElement(element) && getDaoClass(element.containingFile) != null リネーム処理本体 DAOのリネームによって変更前と後の情報を受け取り、変更前のDAO名情報を基に SQL ディレクト リ側もリネームします。 このメソッドは、リネーム処理が呼び出された際に DAO側のリネームが実行される前 に処理されます。 そのため、 最後に親の renameElement() を呼び出さないと、DAO側はリネームされないため注意してください。 以下サンプルで呼び出している getContentRoot() や getPackagePathFromDaoPath() は独自に実装している拡張関数になるため、「 Doma Tools」のコードも参考に実装してみてください。 override fun renameElement( element: PsiElement, -- リネーム前の要素情報 newName: String , -- リネーム後の要素名 usages: Array < out UsageInfo>, -- 対象要素の参照リスト listener: RefactoringElementListener?, ) { // 変更前要素情報からDAOクラス情報を取得 val daoClass = getDaoClass(element.containingFile) ?: return val project = element.project val virtualFile = element.containingFile.virtualFile ?: return // DAOパッケージ名を基にSQLディレクトリ要素を取得 project.getContentRoot(virtualFile)?.let { element.module?.getPackagePathFromDaoPath(virtualFile)?.let { // ディレクトリ名がDAOクラス名と一致するディレクトリ名をリネーム if (it.name == daoClass.name) { it.rename(it, newName) } } } // 親のリネーム処理を呼び出す super .renameElement(element, newName, usages, listener) } 動かしてみる デバッグ 環境でDAOクラス名やファイルのリネームによって対応する SQL ディレクト リ名も一緒に変更されることを確認して見ましょう。 デバッグ 起動方法は前回と同じく、 デバッグ起動する で実行してください。 参考： 「 Doma Tools」実装コード 「 Doma Tools」の リファクタリング 機能 は、以下コードで実装しています。 DaoRenameProcessor さいごに 今回は リファクタリング 機能の実装についてご紹介しました。 「 Doma Tools」では Doma のDAOと SQL の紐づけに対応し、ファイルジャンプだけでなくファイル名の連動も強化しています。 特定のファイル間での連携が必要なプロジェクトにおいて、 リファクタリング 機能を用意して開発効率を向上させましょう！ 「 Doma Tools」へのレビューも投稿していただけますと大変励みになります🙇‍♀️ Doma Tools マーケットプレースページ 本 プラグイン は OSS として Domaコミュニティ へ寄贈されています。 不具合修正や機能要望、ディスカッションにもぜひご参加ください。 採用ページ 執筆： @terao.haruka レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

みなさんこんにちは、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 で執筆されました ）