こんにちは。クロス イノベーション 本部 クラウド イノベーション センターの柴田です。 この記事では Visual Studio Code で GitHub Copilot の agent mode と Remote Development を併用した場合に MCP サーバーがどこで実行されるのかをご紹介します。 はじめに GitHub Copilot とは Remote Development とは 前提条件 MCP サーバーはどこで実行されるのか おわりに 参考資料 はじめに GitHub Copilot とは GitHub Copilot は GitHub が提供するコーディングアシスタントです。 AI を活用してコードの補完や生成など様々な機能を提供します。 version 1.99 からは MCP クライアントとしても利用できるようになりました。 Remote Development とは Remote Development は Visual Studio Code の 拡張機能 の 1 つです。 ソースコード を開いたりコマンドや 拡張機能 を実行したりといった Visual Studio Code の各種操作を、ローカル環境と同じようにコンテナ・リモートマシン・ Windows Subsystem for Linux などのリモート環境上で行うことができます。 1 前提条件 この記事は以下の環境を前提とします。 Visual Studio Code version 1.100.2 Remote - SSH version 0.120.0 GitHub Copilot version 1.322.0 この記事の内容の動作確認は Remote Development のうち Remote - SSH でのみ行っています。 MCP サーバーはどこで実行されるのか GitHub Copilot の agent mode と Remote Development を併用した場合に MCP サーバーはどこで実行されるのでしょうか。 microsoft/vscode#243687 には以下のようにコメントされています。 VS Code will run the tool wherever it is configured. If it is configured in your user settings, then it will run on the VS Code 'host'. If they are configured in your remote settings or in workspace settings, then they will be run in the remote. つまり先ほどの質問への答えは以下のようになります。 MCP サーバの構成をどこに記述したか MCP サーバがどこで実行されるか ユーザー設定（ローカルの settings.json ） ローカル環境 リモート設定（リモートの settings.json ） リモート環境 ワークスペース設定（ワークスペースの .vscode/mcp.json ） ワークスペース のある環境（≒ リモート環境） もし MCP サーバーが期待通り起動しない場合は、 MCP サーバーの設定がどこに記述されているか、そして MCP サーバーがどこで実行されているかを確認してみるとよいでしょう。 おわりに この記事では Visual Studio Code で GitHub Copilot の agent mode と Remote Development を併用した場合に MCP サーバーがどこで実行されるのかをご紹介しました。最後までお読みいただき、ありがとうございました。 参考資料 MCP servers run on local machine, not in remote · Issue #10920 · microsoft/vscode-remote-release Vscode in WSL using other environment to connect to MCP Servers · Issue #245050 · microsoft/vscode Allow running and detecting servers on WSL2 · Issue #243687 · microsoft/vscode 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @shibata.takao 、レビュー： @kobayashi.hinami （ Shodo で執筆されました ） https://code.visualstudio.com/docs/remote/remote-overview より引用。 ↩

こんにちは。クロス イノベーション 本部 クラウド イノベーション センターの柴田です。 最近 Model Context Protocol ( MCP ) が注目を集めていますね。 一部の MCP サーバーは実行に資格情報を必要とします。例えば以下は https://github.com/makenotion/notion-mcp-server の設定例です。 環境変数 OPENAPI_MCP_HEADERS に Notion の integration secret を設定する必要があります。 { " servers ": { " notionApi ": { " command ": " npx ", " args ": [ " -y ", " @notionhq/notion-mcp-server@v1.7.0 " ] , " env ": { " OPENAPI_MCP_HEADERS ": " { \" Authorization \" : \" Bearer ntn_**** \" , \" Notion-Version \" : \" 2022-06-28 \" } " } } } } しかし MCP クライアントの設定ファイルに資格情報を平文でハードコーディングするのはセキュリティの観点から望ましくありません。そこでこの記事では MCP クライアントとして Visual Studio Code を使用する場合に MCP サーバーの実行に必要な資格情報をパラメーター化する方法をご紹介します。 入力変数を利用して資格情報をパラメーター化する おわりに 参考資料 入力変数を利用して資格情報をパラメーター化する Visual Studio Code では 入力変数 を利用して Task や Debugging の設定ファイルの値をパラメーター化できます。同様に MCP サーバーの設定でも入力変数を利用して実行に必要な資格情報をパラメーター化できます。 先ほどの Notion MCP サーバーの設定を入力変数を使って書き直すと以下のようになります。ハードコーディングしていた integration secret がパラメーター化されています。 { " inputs ": [ { " description ": " Notion Integration Secret ", " id ": " notion-integration-secret ", " password ": true , " type ": " promptString " } ] , " servers ": { " notionApi ": { " command ": " npx ", " args ": [ " -y ", " @notionhq/notion-mcp-server@v1.7.0 " ] , " env ": { " OPENAPI_MCP_HEADERS ": " { \" Authorization \" : \" Bearer ${input:notion-integration-secret} \" , \" Notion-Version \" : \" 2022-06-28 \" } " } } } } 早速 MCP サーバーを起動してみましょう。 すると integration secret を入力するプロンプトが表示されます。 integration secret を入力して MCP サーバーを起動しました。試しに適当なプロンプトを入力してみます。 MCP サーバーが正常に動作していることが確認できました。 inputs ブロックを見ると値が格納されていることがわかります（ password=true なので表示される値は * に置換されています）。 カーソルを合わせると入力変数の値を編集またはクリアできます。 入力した値は Visual Studio Code によって永続化されます。試しに PC を再起動してみましたが integration secret は残っていました。 Visual Studio Code の公式ドキュメント には以下のように書かれています。 // 💡 Inputs are prompted on first server start, then stored securely by VS Code. 具体的にどうセキュアに保存されるのかは確認できませんでした。「入力した資格情報は Visual Studio Code によってローカルに保存される」ということは認識しておきましょう。 おわりに この記事では Visual Studio Code で MCP サーバーの実行に必要な資格情報をパラメーター化する方法をご紹介しました。最後までお読みいただき、ありがとうございました。 参考資料 Use MCP servers in VS Code (Preview) Variables reference 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @shibata.takao 、レビュー： @handa.kenta （ Shodo で執筆されました ）

こんにちは。 エンタープライズ 第三本部 マーケティング IT部の熊倉です。 このブログでは、 高速に動作する分散処理エンジン「 Apache Spark」 と オープンテーブルフォーマット「Delta Lake」 を基盤としたレイクハウス環境を構築できるDatabricks上で管理しているデー タセット に対して、 名寄せ 処理を行うアプローチについて紹介します。 実際のノートブックの処理についても紹介しようと思っていますが、想定よりも内容が多くなってしまったので、 名寄せ の概要を紹介する「概要編」、 ソースコード など具体的な 名寄せ 処理の具体的な内容を紹介する「 決定論 的マッチング編」「確率的マッチング編」の三部作にしようと思います。 Databricksで実現するデータ名寄せ【概要編】 Databricksで実現するデータ名寄せ【決定論的マッチング編】 Databricksで実現するデータ名寄せ【確率的マッチング編】（本記事） 本記事は確率的マッチング編となります。 名寄せ 処理の概要について説明したブログ記事も公開しておりますので、 名寄せ 処理にまだ馴染みのない方は、ぜひそちらもご覧いただけると幸いです。 本記事ではZinggというライブラリを利用し、確率的マッチングを行う具体的な処理内容や流れについて説明します。Zinggの概要については「Databricksで実現するデータ 名寄せ 【概要編】」で紹介しておりますので、こちらも合わせてご覧ください。 また、本記事の内容はZinggが公開しているExampleとDatabricksが公開しているソリューション アクセラ レータを参考にしております（Example + ソリューション アクセラ レーター + 自分の方でDatabricksの設計に合わせて加筆変更を加えたような形） 適宜こちらのページも参考にしていただきながら本記事の方も読んでいただけると良いかと思います。 Zingg https://github.com/zinggAI/zingg/blob/main/examples/databricks/FebrlExample.ipynb https://www.zingg.ai/documentation-article/identity-resolution-on-databricks-for-customer-360 Databricks https://notebooks.databricks.com/notebooks/RCG/product-er-with-images/index.html#product-er-with-images_1.html では、早速データの 名寄せ を開始していきましょう！ Zinggを利用した名寄せ処理の概要 1. ライブラリをインストールする 1. クラスターにライブラリをインストールする 1. ZinggのJARファイルをGitHubからダウンロードします。 2. 適当なVolumeにJARファイルを配置する 3. クラスターの設定からライブラリをインストールする 2. ノートブックでZinggのPythonパッケージをインストールする 2. 名寄せ処理に必要なモジュールやライブラリをインストールする ライブラリのインストール Zinggで利用するワークスペースを整理 名寄せ処理で利用する関数の定義、モジュールのimport 3. Zinggの設定（Config）を定義 4. Zinggのインプット、アウトプット先を設定する 5. フィールドの属性を指定する 6. パラメータを設定する 7. トレーニングデータ作成ジョブを実行する 8. ラベリングに使用するデータセットを作成する 9. ラベリングを行う 10. モデルのトレーニング 11. マッチング結果を確認する まとめ Zinggを利用した 名寄せ 処理の概要 Zinggを利用した 名寄せ は次のステップで行います。 まず最初に 名寄せ 対象デー タセット の項目の属性（テキストや数値項目なのか、どのようなマッチングをしたいかなど）をそれぞれ定義します 定義した内容を元にデー タセット から一致している可能性の高いペアをサンプリングします サンプリングされたペア候補を元に、ユーザがペアの一致、不一致、不明を判断し、ラベリングを行います モデルのト レーニン グに十分な数が集まるまでサンプリングとラベリングを繰り返します 教師データを元にモデルを作成し、 クラスタ ー化を行います クラスタ ー化されたデー タセット ではペアの一致確率が確認できます 一致確率が確認できるので、「XX%以上は一致、XX ~ YY%はユーザで改めて手動マッチング、YY%以下は別人とする」といったようなオペレーションが可能です では、次から実際にDatabricksでZinggの 名寄せ 処理を行う方法について、具体的に紹介していきます。 1. ライブラリをインストールする Zinggをノートブックで利用するためには、次の2ステップが必要になります。 （ノートブックにアタッチする） クラスタ ーにライブラリをインストールする ノートブックでzinggの Python パッケージをインストールする 手順を順番に紹介します。 1. クラスタ ーにライブラリをインストールする 1. ZinggのJARファイルを GitHub からダウンロードします。 以下の GitHub の リポジトリ から、最新のZingg JARファイルをダウンロードします。（25/5月現在0.4.0が最新） https://github.com/zinggAI/zingg/releases 2. 適当なVolumeにJARファイルを配置する ダウンロードしたJARファイルを、任意のVolumeにアップロードします。 クラスタ ーのライブラリは ワークスペース 、Volume、S3などの クラウド ストレージ等に配置されてある必要があるので、Volume以外の場所が良い場合は適宜配置先を変更してください。 https://docs.databricks.com/aws/en/libraries/cluster-libraries 3. クラスタ ーの設定からライブラリをインストールする クラスタ ー設定ページを開き、「ライブラリ」タブから「新規をインストール」を選択し、ステップ2でVolumeに配置したJARファイルを指定してインストールします。 2. ノートブックでZinggの Python パッケージをインストールする 1. でインストールした クラスタ ーをアタッチしたノートブック上で、以下のセルを実行し、Zinggの Python パッケージをインストールします。 %pip install zingg dbutils.library.restartPython() 2. 名寄せ 処理に必要なモジュールやライブラリをインストールする Zinggの他に、ノートブックで使用するその他のライブラリやモジュール、変数をあらかじめインストールまたは準備しておきます。 ライブラリのインストール データを表形式で整形して表示するための Python パッケージ tabulate をインストールします !pip install tabulate dbutils.library.restartPython() Zinggで利用する ワークスペース を整理 Zinggで 名寄せ 対象とするデー タセット の格納場所や、処理結果の出力先となるパスを指定します。 ただし、ここに関して少し注意が必要で、Zinggは Apache Sparkで動作する 名寄せ ライブラリですが、Databricksとネイティブに統合されているわけではないため、実装する際に気をつけなければいけないポイントがあります。 具体的には次のような点に注意が必要です。 Zinggで 名寄せ したいデー タセット はDatabricks上では外部テーブルとして登録されている必要がある Zinggで作成されるデー タセット や、ト レーニン グデータ、モデルなどはUnity Catalogのテーブルとして登録することができないため、DBFSやボリュームなどに作成される ZinggとDatabricks、 クラウド ストレージの関係をまとめると次のような図になります。 そのため、事前に 「インプットしたいデー タセット を外部テーブルとして作成」し、「Zinggの出力先となるVolumeを作成」しておく必要があります。 本記事では作成方法については割愛させていただきますが、以下ページを参考に作成していただけると良いかと思います。 https://docs.databricks.com/aws/ja/tables/external https://docs.databricks.com/aws/en/sql/language-manual/sql-ref-volumes ノートブックでは次のように変数にパスを格納しておきます。 # Zinggで作成されるデータセットや、トレーニングデータ、モデルが格納されるVolume # catalog, schema, volumeはそれぞれ適当な値を指定してください。 zinggDir = "/Volumes/catalog/schema/volume" # モデルのID。名寄せの処理ごとに編集してください。 modelId = "hogehoge-model" # 後述の名寄せ処理でラベル付けした情報が格納されるフォルダ MARKED_DIR = zinggDir + "/" + modelId + "/trainingData/marked/" UNMARKED_DIR = zinggDir + "/" + modelId + "/trainingData/unmarked/" 名寄せ 処理で利用する関数の定義、モジュールのimport 後続の処理で利用する関数を定義したり、モジュールを先にimportします。 import pandas as pd import numpy as np import time import uuid from tabulate import tabulate from ipywidgets import widgets, interact, GridspecLayout import base64 import pyspark.sql.functions as fn ##this code sets up the Zingg Python interface from zingg.client import * from zingg.pipes import * def cleanModel (isFull= False ): if (isFull): dbutils.fs.rm(zinggDir + "/" + modelId, recurse= True ) else : dbutils.fs.rm(MARKED_DIR, recurse= True ) # drop unmarked data dbutils.fs.rm(UNMARKED_DIR, recurse= True ) return # assign label to candidate pair def assign_label (candidate_pairs_pd, z_cluster, label): ''' The purpose of this function is to assign a label to a candidate pair identified by its z_cluster value. Valid labels include: 0 - not matched 1 - matched 2 - uncertain ''' # assign label candidate_pairs_pd.loc[ candidate_pairs_pd[ 'z_cluster' ]==z_cluster, 'z_isMatch' ] = label return def count_labeled_pairs (marked_pd): ''' The purpose of this function is to count the labeled pairs in the marked folder. ''' n_total = len (np.unique(marked_pd[ 'z_cluster' ])) n_positive = len (np.unique(marked_pd[marked_pd[ 'z_isMatch' ]== 1 ][ 'z_cluster' ])) n_negative = len (np.unique(marked_pd[marked_pd[ 'z_isMatch' ]== 0 ][ 'z_cluster' ])) return n_positive, n_negative, n_total # setup widget available_labels = { 'No Match' : 0 , 'Match' : 1 , 'Uncertain' : 2 } # dbutils.widgets.dropdown('label', 'Uncertain', available_labels.keys(), 'Is this pair a match?') 3. Zinggの設定（Config）を定義 Zinggではモデルを作成する際、必要な設定情報はすべて Config （実体は JSON オブジェクト）を介して渡すことになります。 https://docs.zingg.ai/latest/stepbystep/configuration #Zinggを動作させるの必要なConfigの作成をサポートするクラス args = Arguments() #　モデル名やZinggの作業ワークスペースをセット args.setModelId(modelId) args.setZinggDir(zinggDir) 4. Zinggのインプット、アウトプット先を設定する インプット（ 名寄せ 対象デー タセット の格納先）とアウトプット（処理結果の出力先）を設定します # 名寄せ対象のデータセット # 前述しましたが外部テーブルとして登録されてある必要があります。 input_path = spark.sql( "DESCRIBE DETAIL catalog.schema.table" ).select( 'location' ).collect()[ 0 ][ 'location' ] # Pipeというクラスより、インプットのデータセットを指定する inputPipe = Pipe(name= 'input' , format = 'delta' ) inputPipe.addProperty( 'path' , input_path ) # Argumentsに追加 args.setData(inputPipe) # アウトプットとなるデータセットやモデルが格納されるDBFS上のパス output_path = zinggDir + "/" + modelId + "/outputData" # Pipeというクラスより、アウトプットのデータセットを指定する outputPipe = Pipe( "resultOutput" , format = "delta" ) outputPipe.addProperty( "path" , output_path) # Argumentsに追加 args.setOutput(outputPipe) 5. フィールドの属性を指定する 次に、Zinggがマッチング処理の中でフィールドの取り扱いについて判断するために、使用するフィールド毎に属性を指定します。 マッチのタイプは以下の中から指定できます。詳細はZinggのドキュメントを参照してください。 https://docs.zingg.ai/latest/stepbystep/configuration/field-definitions マッチタイプ 説明 適用対象 FUZZY タイポ、略語、その他のバリエーションを含む大まかなマッチ。 string, integer, long, double, date EXACT バリエーションを許容しない。国コード、PINコード、およびバリエーションが想定されないその他のカテゴリ変数に適しています。 string, integer, long, date, boolean DONT_USE 出力には表示されますが、計算は行われません。出力に必要なIDなどのフィールドに役立ちます。 showConcise がtrueに設定されている場合、DONT_USEフィールドはラベル付け中にユーザーに表示されません。 any EMAIL @文字の前のメールのID部分のみをマッチします。 any PINCODE xxxxx-xxxxのようなPINコードをマッチします（xxxxx付き）。 string NULL_OR_BLANK デフォルトでは、Zinggはnullをマッチとして扱いますが、FUZZYのような別のマッチタイプを持つフィールドにこれ（NULL_OR_BLANK）を追加すると、Zinggはnull値の機能を構築して学習します。 string, integer, long, date, boolean TEXT 2つの文字列間の単語の重複を比較します。 タイプミス があまりない記述的なフィールドに適しています。 string NUMERIC 文字列から数字を抽出し、両方の文字列間で同じものがいくつあるかを比較します（例：アパート番号）。 string NUMERIC_WITH_UNITS 製品コードまたは単位付きの数字を抽出します（例：16gbの文字列）。両方の文字列間で同じものがいくつあるかを比較します。 string ONLY_ ALPHABETS _EXACT アルファベット文字のみを見て、それらが完全に同じであるかどうかを比較します。文字列内の数字が問題ではない場合（例：建物を調べているが、フラット番号を無視したい場合）。 string ONLY_ ALPHABETS _FUZZY 文字列内の数字を無視し、あいまいな比較を実行します。 タイプミス のある住所などのフィールドに役立ちます。NUMERICを使用して番地を個別に調べたい場合。 string MAPPING_(FILENAME) タイプミス 、略語、および指定された値に対するその他のバリエーションとのマッチング。ニックネーム、性別、および会社略語などの場合に使用できます。たとえば、 IBM 、Int. Biz. MachineをInternational Business Machineに、M、0、MrをMaleに（つまり、複数のエンティティを単一のエンティティに） マッピング する場合。 string ノートブックでは次のように設定します。 # フィールド毎にマッチタイプを指定します。 # 名寄せ処理をしたいデータセット毎に実際は設定してください rec_id = FieldDefinition( "rec_id" , "string" , MatchType.DONT_USE) name = FieldDefinition( "name" , "string" , MatchType.FUZZY) ## Match Typeは複数指定可能です。 email = FieldDefinition( "email" , "string" , [MatchType.FUZZY,MatchType.EMAIL]) dob = FieldDefinition( "dob" , "string" , [MatchType.FUZZY,MatchType.NUMERIC]) address = FieldDefinition( "address" , "string" , MatchType.FUZZY) phone = FieldDefinition( "phone" , "string" , [MatchType.FUZZY,MatchType.NUMERIC]) # フィールドの定義をArrayにする fieldDefs = [rec_id, name, email, dob, address, phone] # Argumentsに設定 args.setFieldDefinition(fieldDefs) 6. パラメータを設定する 次に、Spark上で分散処理を行う際のパラメータを設定します。具体的には numPartitions と labelDataSampleSize を設定します。 numPartitions numPartitions は、データを クラスタ 間でどのように分割するかを定義します。 Zinggドキュメント を参照して、データと クラスタ サイズに応じて変更してください。 labelDataSampleSize labelDataSampleSize では、後述する findTrainingData 処理でサンプルする割合を指定できます。サンプリングする割合が大きいほうが、ラベリングする際にケースとして相応しいペアが出力できる可能性が高くなりますが、処理の時間が長くなりすぎる場合もあるので、1/10に減らすなど調整を行ってください。 # Sparkのパーティション数。ドキュメントより推奨はコア数 × 20~30とのこと num_partitions = sc.defaultParallelism * 20 args.setNumPartitions( num_partitions ) # モデルの学習に使用するデータの割合。 # サンプルサイズを小さく保ち、十分なエッジケースを迅速に検出できるよう、0.0001～0.1の間で調整してください。 # サンプルサイズが大きいと、ジョブがfindTrainingDataサンプルを精査するのに時間がかかります。サイズが小さすぎると、Zinggが適切なエッジケースを見つけられない可能性があります。 args.setLabelDataSampleSize( 0.05 ) 7. ト レーニン グデータ作成ジョブを実行する ここまでの設定を用いて、ト レーニン グデータ（ラベリング候補ペア）を作成するジョブ（ findTrainingData フェーズ）を実行します。 options = ClientOptions([ClientOptions.PHASE,"findTrainingData"]) # トレーニングデータを特定するジョブを実行 zingg = ZinggWithSpark(args, options) zingg.initAndExecute() 8. ラベリングに使用するデー タセット を作成する ト レーニン グデータの作成が終わったら、ラベリングに使用するデー タセット を作成します。 ちなみに、ステップ7と8の処理（ト レーニン グデータ作成とラベリング用デー タセット 準備）は、 findAndLabel という単一のフェーズ指定で連続実行も可能です。しかし、ト レーニン グデータの作成には時間がかかる場合があるため、ここでは途中から再開しやすいようにステップを分けて記述しています。 options = ClientOptions([ClientOptions.PHASE, "label" ]) # ラベリングに使用するデータセットを作成するジョブを実施 zingg = ZinggWithSpark(args, options) zingg.init() 次に、ラベリングの候補となるペアが何件あるか確認します。 # get candidate pairs candidate_pairs_pd = getPandasDfFromDs(zingg.getUnmarkedRecords()) # if no candidate pairs, run job and wait if candidate_pairs_pd.shape[ 0 ] == 0 : print ( 'No unlabeled candidate pairs found. Run findTraining job ...' ) else : # get list of pairs (as identified by z_cluster) to label z_clusters = list (np.unique(candidate_pairs_pd[ 'z_cluster' ])) # identify last reviewed cluster last_z_cluster = '' # none yet # print candidate pair stats print ( '{0} candidate pairs found for labeling' .format( len (z_clusters))) ラベリングの候補としていくつペアあるか出力されます。（画像ではラベリングの候補として20ペアあることがわかります） 9. ラベリングを行う いよいよ、抽出された候補ペアに対して実際にラベリングを行います。 ノートブック上に候補ペアがHTML形式で表示され、各ペアに対して「Uncertain（不明）」「Match（一致）」「No Match（不一致）」のいずれかをボタンを押すことでラベリング作業を行います。 （Databricksがノートブック機能を提供している強みですね！） # Label Training Set # define variable to avoid duplicate saves ready_for_save = False # user-friendly labels and corresponding zingg numerical value # (the order in the dictionary affects how displayed below) LABELS = { 'Uncertain' : 2 , 'Match' : 1 , 'No Match' : 0 } # GET CANDIDATE PAIRS # ======================================================== #candidate_pairs_pd = get_candidate_pairs() n_pairs = int (candidate_pairs_pd.shape[ 0 ]/ 2 ) # ======================================================== # DEFINE IPYWIDGET DISPLAY # ======================================================== display_pd = candidate_pairs_pd.drop( labels=[ 'z_zid' , 'z_prediction' , 'z_score' , 'z_isMatch' , 'z_zsource' ], axis= 1 ) # define header to be used with each displayed pair html_prefix = "<p><span style='font-family:Courier New,Courier,monospace'>" html_suffix = "</p></span>" header = widgets.HTML(value=f "{html_prefix}<b>" + "<br />" .join([ str (i)+ "  " for i in display_pd.columns.to_list()]) + f "</b>{html_suffix}" ) # initialize display vContainers = [] vContainers.append(widgets.HTML(value=f '<h2>Indicate if each of the {n_pairs} record pairs is a match or not</h2></p>' )) # for each set of pairs for n in range (n_pairs): # get candidate records candidate_left = display_pd.loc[ 2 *n].to_list() candidate_right = display_pd.loc[( 2 *n)+ 1 ].to_list() # define grid to hold values html = '' for i in range (display_pd.shape[ 1 ]): # get column name column_name = display_pd.columns[i] # if field is image if column_name == 'image_path' : # define row header html += '<tr>' html += '<td><b>image</b></td>' # read left image to encoded string l_endcode = '' if candidate_left[i] != '' : with open (candidate_left[i], "rb" ) as l_file: l_encode = base64.b64encode( l_file.read() ).decode() # read right image to encoded string r_encode = '' if candidate_right[i] != '' : with open (candidate_right[i], "rb" ) as r_file: r_encode = base64.b64encode( r_file.read() ).decode() # present images html += f '<td><img src="data:image/png;base64,{l_encode}"></td>' html += f '<td><img src="data:image/png;base64,{r_encode}"></td>' html += '</tr>' elif column_name != 'image_path' : # display text values if column_name == 'z_cluster' : z_cluster = candidate_left[i] html += '<tr>' html += f '<td style="width:10%"><b>{column_name}</b></td>' html += f '<td style="width:45%">{str(candidate_left[i])}</td>' html += f '<td style="width:45%">{str(candidate_right[i])}</td>' html += '</tr>' # insert data table table = widgets.HTML(value=f '<table data-title="{z_cluster}" style="width:100%;border-collapse:collapse" border="1">' +html+ '</table>' ) z_cluster = None # assign label options to pair label = widgets.ToggleButtons( options=LABELS.keys(), button_style= 'info' ) # define blank line between displayed pair and next blankLine=widgets.HTML(value= '<br>' ) # append pair, label and blank line to widget structure vContainers.append(widgets.VBox(children=[table, label, blankLine])) # present widget display(widgets.VBox(children=vContainers)) # ======================================================== # mark flag to allow save ready_for_save = True ノートブックのアウトプットでは次のようなHTMLが表示されます。 実際にレコードが一致しているか、一致していないかを人の目で1つひとつチェックを行い、ボタンを押してラベリングを行っていきます。 ステップ8で作成されたペア分のチェックが終了したら、次のセルを実行し、内容を保存します。 if not ready_for_save: print ( 'No labels have been assigned. Run the previous cell to create candidate pairs and assign labels to them before re-running this cell.' ) else : # ASSIGN LABEL VALUE TO CANDIDATE PAIRS IN DATAFRAME # ======================================================== # for each pair in displayed widget for pair in vContainers[ 1 :]: # get pair and assigned label html_content = pair.children[ 1 ].get_interact_value() # the displayed pair as html user_assigned_label = pair.children[ 1 ].get_interact_value() # the assigned label # extract candidate pair id from html pair content start = pair.children[ 0 ].value.find( 'data-title="' ) if start > 0 : start += len ( 'data-title="' ) end = pair.children[ 0 ].value.find( '"' , start+ 2 ) pair_id = pair.children[ 0 ].value[start:end] # assign label to candidate pair entry in dataframe candidate_pairs_pd.loc[candidate_pairs_pd[ 'z_cluster' ]==pair_id, 'z_isMatch' ] = LABELS.get(user_assigned_label) # ======================================================== # SAVE LABELED DATA TO ZINGG FOLDER # ======================================================== # make target directory if needed dbutils.fs.mkdirs(MARKED_DIR) # save label assignments # save labels zingg.writeLabelledOutputFromPandas(candidate_pairs_pd,args) # count labels accumulated marked_pd_df = getPandasDfFromDs(zingg.getMarkedRecords()) n_pos, n_neg, n_tot = count_labeled_pairs(marked_pd_df) print (f 'You have accumulated {n_pos} pairs labeled as positive matches.' ) print (f 'You have accumulated {n_neg} pairs labeled as not matches.' ) print ( "If you need more pairs to label, re-run the cell for 'findTrainingData'" ) # ======================================================== # save completed ready_for_save = False 上記のセルを実行すると、これまでにラベリングしたペアの総数（一致、不一致ごとの件数）が出力され、進捗を確認できます。 Zinggのドキュメント では、最低でもマッチと判断できるペアが30~40必要とあり、マッチと判断した数が足りない場合は、あらためて「7. ト レーニン グデータ作成ジョブ実行する」から繰り返し、十分な教師データを収集します。 また、候補となるペアの質が低い場合（明らかに別の人がリストアップされている場合など）、 labelDataSampleSize の割合が小さい可能性があるので、必要に応じてこちらも検討してみてください。 10. モデルのト レーニン グ 十分な数のラベリング済み教師データが収集できたら、それらを基にマッチングモデルを学習します（ trainMatch フェーズ） options = ClientOptions([ClientOptions.PHASE, "trainMatch" ]) #トレーニングジョブを実施します（時間かかります） zingg = ZinggWithSpark(args, options) zingg.initAndExecute() 11. マッチング結果を確認する モデル学習が完了したら、そのモデルを用いて 名寄せ 対象の全データに対して予測を実行し、どのレコードペアが同一エンティティとして判断されたかを確認します。 予測結果が出力されるデー タセット は、前述のZingg設定（ outputPipe ）で指定したパスに格納されます。 この出力デー タセット には、入力データに加えて、Zinggが付与した クラスタ IDや類似度スコアなどの情報が含まれます。 from pyspark.sql.types import StructType, StructField, IntegerType, FloatType, StringType # テーブルの取得 outputDF = spark.read.load(zinggDir + "/" + modelId + "/outputData/" ) # 内容の確認 display(outputDF.orderBy( "z_cluster" ).head( 25 )) 具体的には、以下の列が追加されています。 z_minScore そのレコードが同じ クラスタ 内の別のレコードと持つ最小の類似性スコアを表します。 z_maxScore そのレコードが同じ クラスタ 内の別のレコードと持つ最大の類似性スコアを表します。 z_cluster Zinggによって割り当てられた クラスタ ーのID。同一エンティティと判定されたレコード群には、共通のz_cluster IDが付与されます。 z_cluster をそのまま一意のエンティティを表すユニークIDとして使用できますが、 z_minScore や z_maxScore を元に 閾値 をユーザ側で定義（XX%以上は一致とする。XX ~ YY%はユーザで改めて目検。YY%以下は別人とする等々...）し、任意のオペレーションをすることもできます。 （詳細については、以下のZingg公式ドキュメントもご参照ください） https://www.zingg.ai/documentation-article/step-by-step-identity-resolution-with-python-and-zingg 以上で 名寄せ の一連のステップが全て終了しました！ まとめ 本ブログ記事では、Zinggライブラリを用いた確率的マッチングの具体的な手法を紹介しました。 今回取り上げたZinggのような教師あり 機械学習 を活用する 名寄せ ライブラリも、Databricksのノートブック機能より、データ準備からラベリング、モデル学習、推論までを一貫したワークロードとして効率的に実行できます。 また、今回の記事では1つのデー タセット 内で 名寄せ する方法について取り上げましたが、他にもZinggを使用して、増分するデー タセット に対して継続的に 名寄せ 処理を実施できたり （ runIncremental 、 エンタープライズ 版で利用可能）、複数のデー タセット 間で一致し得るレコードを抽出も実行可能です（ link ）ので、もし興味がある方は是非公式ドキュメントの方もご覧ください。 三記事にわたり 名寄せ の概要からDatabricks上でSplinkによる 決定論 的手法、Zinggによる確率的手法まで 名寄せ のアプローチについて紹介しましたが、いかがだったでしょうか？ 今回の一連の記事が、皆様のデータ活用や 名寄せ 業務の一助となれば幸いです。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @kumakura.koki 、レビュー： @kinjo.ryuki （ Shodo で執筆されました ）

こんにちは。 エンタープライズ 第三本部 マーケティング IT部の熊倉です。 このブログでは、 高速に動作する分散処理エンジン「 Apache Spark」 と オープンテーブルフォーマット「Delta Lake」 を基盤としたレイクハウス環境を構築できるDatabricks上で管理しているデー タセット に対して、 名寄せ 処理を行うアプローチについて紹介します。 実際のノートブックの処理についても紹介しようと思っていますが、想定よりも内容が多くなってしまったので、 名寄せ の概要を紹介する「概要編」、 ソースコード など具体的な 名寄せ 処理の具体的な内容を紹介する「 決定論 的マッチング編」「確率的マッチング編」の三部作にしようと思います。 Databricksで実現するデータ名寄せ【概要編】 Databricksで実現するデータ名寄せ【決定論的マッチング編】（本記事） Databricksで実現するデータ名寄せ【確率的マッチング編】 本記事は 決定論 的マッチング編となります。 名寄せ 処理の概要について説明したブログ記事も公開しておりますので、 名寄せ 処理にまだ馴染みのない方は、ぜひそちらもご覧いただけると幸いです。 本記事ではSplinkというライブラリを利用し、 決定論 的マッチングを行う具体的な処理内容や流れについて説明していきますが、Pysparkの文法など基本的な内容については割愛させていただきます。（Splinkの概要については前編の概要編で紹介してますのでこちらも合わせてご覧ください） では、早速データの 名寄せ を開始していきましょう！ 1. ライブラリをインストールする 2. 名寄せを行いたいデータセットを取り込む 3. ルールを定義する ルールの定義①： SQLで定義する ルールの定義②： block_onを利用する 注意が必要なルール： 等価結合以外の条件 4. マッチ数を確認する cartesianについて match_keyについて ネクストアクション 5. マッチングの実施 6. クラスターを作成する まとめ 1. ライブラリをインストールする 決定論 的マッチング処理における最終的なゴールは、 SQL のWHERE句に相当する条件の組み合わせを作成 することです。 SQL を記述することでも、もちろん 決定論 的マッチングは実現可能ですが、この記事では再利用性や可読性を考慮し、 Python の OSS 名寄せ ライブラリであるSplinkを用いた手法を紹介します。 まずは最初にライブラリをインストールします %pip install splink 2. 名寄せ を行いたいデー タセット を取り込む まず、 名寄せ 対象のデー タセット を取り込みます。 df = spark.read.table( "catalog.schema.table" ) （本記事ではUnity Catalogに登録されているテーブルから読み込んでいますが、もちろんファイルから直接データを読み込むことも可能です） 3. ルールを定義する 次にマッチングに使用するルールを定義します。 決定論 的マッチングは「ルールベースマッチング」とも呼ばれるように、このルール定義のステップが処理の根幹であり、最も重要なステップです。 ルールの定義は大きく分けて2つあります。 ルールの定義①： SQL で定義する ルールの定義方法の1つ目は、 SQL で定義する方法になります。 具体的には次のような形でルールを定義します。 rules = [] rules.append( "l.name = r.name AND l.email = r.email" ) SQL 文中のlおよびrというテーブル エイリアス は、同一テーブルをクロス結合（自己結合）する際の左テーブル (l) と右テーブル (r) をそれぞれ指します。 SQL 文の中でANDやORを使用して複雑な条件も設定できますが、OR条件はパフォーマンスが低下する可能性があるため、Splinkでは直接の使用は非推奨とされています。 OR条件のように複数の条件のいずれかに合致する場合を扱いたい場合は、各条件を個別のルールとしてrulesリスト（配列）に追加することで、同等の処理を実現できます。 具体的には、 rules.append( "l.name = r.name OR l.email = r.email" ) というルールを設定したい場合、 rules.append( "l.name = r.name" ) rules.append( "l.email = r.email" ) のようにリストに追加します。（ルールはリストに格納された順に評価されます） 補足すると、OR条件を含む結合は非等価結合となり、テーブルの直積に近い処理が必要になるため、一般的にパフォーマンスが低下します。Splinkでは、複数のルールをリストに格納することで、内部的にUNIONとNOTを組み合わせた処理に変換し、OR条件と同等の結果をより効率的に得られるように工夫されています。（詳細はSplinkの公式ドキュメントをご参照ください） 詳細については、以下Splink公式ドキュメントに紹介されているので、こちらも合わせてご確認ください。 https://moj-analytical-services.github.io/splink/topic_guides/blocking/performance.html ルールの定義②： block_onを利用する ルールの定義方法の2つ目は、Splinkで用意されている block_on 関数の利用になります from splink import block_on rules.append(block_on( "dob" , "address" )) Splinkの関数 block_on は、 SQL の l.dob = r.dob AND l.address = r.address と変換されます。 注意が必要なルール： 等価結合以外の条件 単純な列の一致比較（等価結合）以外、例えばLevenstein距離（編集距離）が特定の 閾値 以上であるといった条件（非等価結合）を用いる場合、多くの SQL エンジンでは、全レコードの総当たりに近いペア計算が発生し、計算量が膨大になる傾向があります。このような非等価結合を含むルールを設定する際は、パフォーマンスへの影響に十分な注意が必要です。 要件として、マッチングルールとして設定する必要がある場合もあるかと思いますが、注意が必要な条件になります。 4. マッチ数を確認する マッチング処理を行いレコードを突合する前に、3. で設定したルールで何件のレコードがマッチされるか確認できます。 from splink import SparkAPI from splink.blocking_analysis import cumulative_comparisons_to_be_scored_from_blocking_rules_data db_api = SparkAPI(spark_session=spark) # ruleの配列には以下を格納 # "l.name = r.name AND l.email = r.email" # block_on("dob", "address") count = cumulative_comparisons_to_be_scored_from_blocking_rules_data( table_or_tables=df, blocking_rules=rules, db_api=db_api, link_type= "dedupe_only" , unique_id_column_name= "id" ) display(count) 出力結果は以下のようになります。 ルールはリスト（ rules ）に入っている順に評価されるので、上記の ソースコード の例では "l.name = r.name AND l.email = r.email" block_on("dob", "address") の順に評価されます。 出力結果より、 "l.name = r.name AND l.email = r.email" のルールでは4345件がマッチと判断され、 block_on("dob", "address") のルールでは348件マッチと判断され、合計で4693件のペアがマッチと判断されたことが分かります。 注 : 「 block_on("dob", "address") のルールでは348件マッチ」とありますが、これは block_on("dob", "address") のルール 単体 でヒットしたペアが348件という訳ではなく、 "l.name = r.name AND l.email = r.email" のルールでヒットしなかったペアのうち、348件が2. のルールにヒットした、ということになります。 ちなみに、リストに格納されるルールの順を逆にすると以下のような出力結果になります。（ダミーデータの都合上、マッチするペアがほぼ一緒だったりしますが...） cartesianについて cartesian カラムに78,131,250という数値が入っていますが、デー タセット 内で作成可能な全てのユニークなペアの総数になります。これは（レコードの総数）* （レコードの総数 -1 ）/ 2 で求められます。 （今回使用したダミーデータのレコード総数は12,501件であるため、作成可能なペアの総数は 12,501 × 12,500 / 2 = 78,131,250 となります） match_keyについて 出力結果には match_key カラムがありますが、これは各ルールに割り当てられた識別キー（インデックス）です。 後述のマッチング結果を確認する中で改めて登場します。 ネクス トアクション マッチ数を確認し必要に応じて3. で設定したルールの見直しを行います。 マッチ候補となるペア数は、後続のマッチング処理における計算リソースや処理時間に直接影響するため、「マッチ数が過大になっているルールはないか（処理負荷が高すぎないか）」、逆に「マッチ数が極端に少なく、効果の薄いルールはないか」といった観点で確認します。 基本的には、ルールをより厳しくする方向（例：リストに格納するルール数を調整する、ANDで条件を追加するなど）で再定義を検討しますが、実際にはプロジェクトごとの要件（精度、再現率、処理時間など）を総合的に加味して調整していくことになります。 5. マッチングの実施 ルールの定義が完了したら、実際にマッチングを行い突合したレコードを確認します。 settings = SettingsCreator( link_type= "dedupe_only" , blocking_rules_to_generate_predictions=rules, # ユニークな列を指定します。 unique_id_column_name= "id" , ) linker = Linker(df, settings, db_api=db_api) # マッチングの実施 df_predict = linker.inference.deterministic_link() df_predict_spark = df_predict.as_spark_dataframe() df_predict_spark はマッチングで突合されたレコードのペアが格納されたデータフレームになります。 display(df_predict_spark.count()) display(df_predict_spark.head( 15 )) ペアの情報のほか、出力結果には match_key カラムが追加されています。 こちらは「4. マッチ数を確認する」で確認できる match_key に対応しており、どのルールによって検出されたペアなのかを確認することができます。 （図の例だと、52行目のペアはmatch_keyが0、つまり"l.name=r.name AND l.email = r.email"というルールによってヒットしたペアで、53行目のペアはmatch_keyが1、つまり block_on("dob", "address") というルールによってヒットしたことが分かります） 6. クラスタ ーを作成する 同一ペアの検出は5. のステップで完了しましたが、ステップ6ではさらに進んで、同一と判定されたエンティティ（レコード群）に対して新しいユニークIDを付与します（この処理を クラスタリング 、または クラスタ ー化と呼びます）。 from pyspark.sql.functions import col # クラスター化の実行 clusters = linker.clustering.cluster_pairwise_predictions_at_threshold(df_predict) df_cluster_spark = clusters.as_spark_dataframe() # 結果の確認 display(df_cluster_spark.orderBy(col( "cluster_id" )).head( 15 )) cluster_id カラムが追加され、同一エンティティと判定されたレコード群ごとにユニークなIDが付与されていることが確認できます。 名寄せ 処理後のデー タセット では、この付与された cluster_id を新たなユニークIDとして扱うことになります。 以上で 名寄せ の一連のステップが全て終了しました！ まとめ 本ブログではSplinkを使用した 決定論 的マッチングの具体的な手法について簡単に紹介しました。 処理自体は比較的シンプルかなと思いますが（冒頭で書いたように SQL のWHERE句を作るのが最終的なゴールなので）、実際のプロジェクトでは、このルール定義部分で難航することが多いのかなと思います。 以上、Databricks上で実現するデータ 名寄せ 【 決定論 的マッチング】編でした。 次回はDatabricks上で実現するデータ 名寄せ 【確率的マッチング】編になります！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @kumakura.koki 、レビュー： @akutsu.masahiro （ Shodo で執筆されました ）

こんにちは。 エンタープライズ 第三本部 マーケティング IT部の熊倉です。 このブログでは、 高速に動作する分散処理エンジン「 Apache Spark」 と オープンテーブルフォーマット「Delta Lake」 を基盤としたレイクハウス環境を構築できるDatabricks上で管理しているデー タセット に対して、 名寄せ 処理を行うアプローチについて紹介します。 実際のノートブックの処理についても紹介しようと思っていますが、想定よりも内容が多くなってしまったので、 名寄せ の概要を紹介する「概要編」、 ソースコード など具体的な 名寄せ 処理の具体的な内容を紹介する「 決定論 的マッチング編」「確率的マッチング編」の三部作にしようと思います。 Databricksで実現するデータ名寄せ【概要編】（本記事） Databricksで実現するデータ名寄せ【決定論的マッチング編】 Databricksで実現するデータ名寄せ【確率的マッチング編】 本記事は概要編で、 名寄せ 処理について概要、Databricksで 名寄せ 処理を行うメリットについて紹介します。 名寄せ 処理の基本をご存知の方は、本記事を読み飛ばしていただき、「 決定論 的マッチング編」または「確率的マッチング編」からお読みいただいても構いません 1. はじめに 1.1 名寄せとは 1.2 Entity Resolution と Identity Resolution 1.3 日本の名寄せ処理事情 1.4 国内の名寄せソリューション 2. 名寄せ処理の概要 2.1 名寄せ処理のステップ 2.2 偽陽性と偽陰性 2.3 決定論的マッチングと確率的マッチング 1. 決定論的マッチング 2. 確率的アイデンティティ解決 決定論的マッチングと確率的マッチングの選択 3. Databricks上での名寄せ 3.1 Databricksの利用 3.2 テックブログで取り上げるライブラリ Splink Zingg 1. はじめに 1.1 名寄せ とは 複数のレコードから、同一のエンティティ（現実世界で一意の顧客や製品など）を特定する操作を 名寄せ （英語だとEntity Resolution等）と呼びます。 1つのデー タセット 内で発生している重複を解消する場合や、共通IDが存在しない複数のデー タセット 間でユニークなエンティティを特定したい場合に 名寄せ 処理は実施されます。 エンティティは、企業が個別の単位として測定したいものなら何でも該当します。 （例えば、B2C企業だと「顧客」や「製品」、「 サブスクリプション 」、 B2B 企業だと「チーム」「企業」などが挙げられます） 1.2 Entity Resolution と Identity Resolution エンティティが「顧客」の場合の 名寄せ は、 アイデンティティ 解決（Identity Resolution）とも呼ばれることもあります。 アイデンティティ 解決の主要な目的の一つは、顧客に関するあらゆる情報を統合し、多角的な顧客理解を可能にする「カスタマー360」（360度顧客ビュー）の構築です。これの実現は、 マーケティング 効果の向上、顧客体験の最適化、効率的な顧客対応に不可欠です。 歴史的に見ると、このための機能は、金融機関における初期の顧客情報システムであるMCIFのようなデータベース マーケティング システムから始まり、その後、 CRM 、CDPといった様々なシステムで開発・実装されてきました。 1.3 日本の 名寄せ 処理事情 日本の情報が格納されたデー タセット に対して 名寄せ を行いたい場合、日本語特有の課題が存在します。 例えば、 ひらがな、カタカナ、漢字と文字の種類が多いこと 例（類似度について） 例えば、「Robert」と「Robelt」という文字列ペアと、「渡邉」と「渡辺」という文字列ペアは、どちらも編集距離（ここでは、1文字置換のコストを1とします）は同じ1です。しかし、単純に「編集距離/文字列長」で誤り率を評価すると、「Robert / Robelt」（6文字中1文字の違い）は約16.7%ですが、「渡辺/渡邉」（2文字中1文字の違い）は50%となり、後者の方が不一致度が大きく評価される傾向があります。このように、短い文字列（特に漢字2文字など）では、1文字の違いが全体に与える影響が相対的に大きくなってしまいます。 漢字については複数の読み方が存在しており、ふりがなの変換も難しいこと 例: 東海林（とうかいりん、しょうじ）など 住所の体系がかなり複雑なこと 日本の住所の正規化、 名寄せ の難易度の高さについて度々取り上げられ話題になります。 例： 「日本の住所のヤバさ」知れ渡る　正規化・名寄せ問題、Twitterトレンドに 1.4 国内の 名寄せ ソリューション 上記のような理由で日本語での 名寄せ は他の言語に比べると難しい傾向にあります。そのため、国内では従来より ゴールデンレコード（信頼できるソース）となる辞書データを所有 しており、 データの正規化を行える 企業が 名寄せ ソリューションを提供してきた背景があります。 例: 中小企業の辞書データを所有する企業が提供する会社の 名寄せ ソリューションや、住所辞書を所有する企業が提供する人の 名寄せ ソリューションなど 2. 名寄せ 処理の概要 2.1 名寄せ 処理のステップ 名寄せ 処理のステップは大きく 「対象データの分析」「 名寄せ の計画・設計」「対象データの前処理」「対象データのマッチング」 に分かれます。 対象データの分析 名寄せ を行いたいデー タセット について、項目ごとにカーディナリティや存在するデータの傾向などを分析・調査します。 名寄せ の計画・設計 名寄せ 処理のスケジュールや目的を設定します。目的によって、 名寄せ 処理の誤りをどの程度許容できるか（あるいは全く許容できないか）が異なるため、あらかじめ明確に定義し、関係者間で合意を得ておくことが必要です。 また、ルールベースで 名寄せ 処理を行う場合、この段階で 名寄せ ルールを定めます。 例）氏名と生年月日、住所が一致した場合は同一人物とする 対象データの前処理 データの内容は基本的に直接改変せず、後述のマッチング処理を効率良く行うために、表記揺れを吸収するようなデータの整形を行います。ただし、豊富な辞書データ（正本データ）を 保有 する従来型 名寄せ サービスなどでは、この段階で正本データに基づき表記の修正まで実施することもあります。 対象データのマッチング 前処理が完了した対象データに対してマッチング処理を行います。 また、対象データに対してマッチング処理を行った結果、（一般的には）同一とされたエンティティに対して新しいユニークなIDを付与します。 マッチング手法には ルールベースの 決定論 的マッチング と エンティティの一致度を確率で表現する確率論的マッチング が存在します。これらの詳しい処理内容については後述します。 2.2 偽陽性 と 偽陰性 ある情報を”分類”する際、その予測結果と実際の値（正解）パターンは以下の4つに分類できます。 真陽性 (True Positive, TP): 実際に陽性であるものを正しく陽性と予測できたケース 例: 実際に同一人物のレコードを同一人物と判断 真陰性 (True Negative, TN): 実際に陰性であるものを正しく陰性と予測できたケース 例: 実際に別人物のレコードを別人物と判断 偽陽性 (False Positive, FP): 実際には陰性であるものを、 誤って 陽性と予測してしまったケース 例: 実際は別人物なのにレコードを同一人物と判断 偽陰性 (False Negative, FN): 実際には陽性であるものを、 誤って 陰性と予測してしまったケース 例: 実際は同一人物なのにレコードを別人物と判断 名寄せ の目的によって、 偽陽性 と 偽陰性 のどちらを許容するか（反対に許容できないか）を合意しておくことが重要です。 2.3 決定論 的マッチングと確率的マッチング マッチングの手法は大きく、 決定論 的マッチング と 確率論的マッチング の 2 種類に分かれます。 1. 決定論 的マッチング 決定論 的マッチングは、ルール（条件）を定義し、エンティティを同一と見なす 名寄せ 手法です。 主な特徴 ルールベースのマッチング 事前に定義された厳格なルール（例：「氏名と生年月日が完全に一致する」「メールアドレスが完全に一致する」など）に基づいてレコードを比較し、条件に合致した場合にのみ同一エンティティと 判断 します。 利点 高精度 誤判定（ 偽陽性 ）が少なく、信頼性が高いです。特にパーソナライズされたコミュニケーションなど、精度が重視される用途に適しています。 計算コスト 確率的モデルと比較して、ルールベースのマッチングは計算量が少なく済む場合があります。 解釈可能性 なぜデータが結びつけられたのか、ルールに基づいて明確に説明できます。 欠点・課題 再現率の低さ（見逃しの多さ） ルールが厳格であるため、名前の表記揺れ（例: 「渡辺」 と 「渡邉」）、入力ミス、データの欠損（例: 郵便番号がない）などがあると、実際には同一人物であってもルールに合致せず、見逃してしまう（ 偽陰性 ）可能性が高くなります。 ルール設定の複雑さ 偽陰性 を低くしようと、より多くのパターンに対応しようとすると、ルールが非常に複雑になります まとめ 決定論 的マッチングは、明確な情報に基づいて高い精度で顧客情報を統合する強力な手法ですが、データの完全性や表記の揺れに弱く、すべての関連データを見つけ出す(再現率) 点では限界があることを理解して利用する必要があります。 2. 確率的 アイデンティティ 解決 確率論的名前解決とは、ルールに一致するかどうかだけに頼るのではなく、複数の情報や不完全な情報を統計的に評価し、異なるレコードが同じエンティティを指している「確率」を計算する手法です。 あいまい一致（Fuzzy Matching）と呼ばれることもあります。 主な特徴 証拠に基づくアプローチ 氏名、生年月日、住所、メールアドレス、位置情報など複数の属性や情報の一致率を算出し、「証拠」として利用します。 単一の属性（例：氏名が同じ、メールアドレスが同じ）だけでは一致と判断せず、複数の証拠を組み合わせ総合的に評価します。 各属性の一致・不一致が、どの程度「同一エンティティである」という結論を支持するか（または否定するか）を重み付けし、総合的な一致確率を算出します。 例えば 、 「田中 一郎、生年月日1990/05/09、郵便番号000 1234」というレコードと、 「田中 市朗、生年月日1990/05/09、郵便番号AB12 3CD」というレコードがあった場合、 名前は完全一致しないものの、他の属性が一致しているため、一致確率（例：98.21%）は高い のように確率をそれぞれ算出します。 閾値 の設定を後から設定でき、柔軟性がある 一致する確率が算出されるので、ユーザーが「どの程度の確率であれば同一エンティティとみなすか」という 閾値 をマッチングを行った後から設定できます。 これにより、 ユースケース に応じて精度と網羅性のバランスを調整できます。 例えば、同一人物であるにも関わらず誤って別人としてしまうこと（ 偽陰性 ）を避けたい場合は 閾値 を低めに、別人なのに同一人物と判断してしまうこと（ 偽陽性 ）を下げたい場合は 閾値 を高めに設定することが可能です。 利点 （ルールベースの 決定論 的マッチングに比べ）より多くのレコードを検出できる 確率論的手法は完全一致しないデータ間でも関連性を見つけ出すことができるため、 決定論 的手法よりも多くのレコードを統合できる可能性があります。 しかし、その性質上、（別人を同一人物として判断してしまう） 偽陽性 は 決定論 的手法よりも高くなる可能性があります。 実際にマッチングされた結果を見ながら、同一かどうかの判断ができる 偽陰性 、 偽陽性 の調整を後から実施できる ルールベースの 決定論 的マッチングの場合、あらかじめルールを定義する必要があり、その定義したルールで目的の 名寄せ ができたかどうかは結果が出力されないと判断ができない。（判断自体も難しい） 欠点・課題 解釈可能性が低い 確率によって一致かどうかを判断するため、究極的に言えば分類結果が誤っている可能性が常に存在する。 決定論 的マッチングは「一致とする」と判断してしまうアプローチなので、上記の点は明確です。 偽陽性 が高くなる場合がある 一致確率を基に判断する性質上、（別人を同一人物として判断してしまう） 偽陽性 は 決定論 的手法よりも高くなる可能性があります。 前述のように 閾値 の調整を行うことである程度調整は可能です。 まとめ 確率論的名前解決は、複数の不確実な情報から統計的に同一性を推定する柔軟なアプローチであり、より多くのデータを統合できる可能性がありますが、メリットとデメリットを理解し、 閾値 をどこに設定するかが重要となる手法です。 決定論 的マッチングと確率的マッチングの選択 上記のように、 決定論 的マッチングと確率的マッチングではそれぞれメリットデメリットが存在しており、どちらに優位性があるという訳ではありません。 例えば、 名寄せ した結果を基にユーザーに対してメールや電話による1on1の施策を行いたい場合、別人同士を同一人物として判断してしまう 偽陽性 が許容されないため、ルールベースの 決定論 的マッチングが適しています。一方、広告のオーディエンスとして利用するなど、ある程度の誤りが許容できる場合（機会損失の方が大きいと考えられる場合）は、確率論的マッチングの方が適しています。 名寄せ した結果どうしたいか（どのような利用を想定しているか）によって、どちらかを選択したり、 あるいは組み合わせて （氏名、住所、電話番号が一致する人は 決定論 的な考え方で同一人物とするが、他の属性の組み合わせについては確率的な考え方で 名寄せ を行うなど） 名寄せ 処理を行なっていくことになります。 3. Databricks上での 名寄せ 3.1 Databricksの利用 Databricksは、 Apache Sparkを基盤とする統合データ分析プラットフォームで、データエンジニアリング、 SQL や Python を利用した分析、 機械学習 、AIモデル開発といったデータ関連のワークロードを一元的に提供するプラットフォームです。 Databricksはデータエンジニアリングを行う主要なインターフェースの一つとしてNotebook環境を提供しています。 Notebookでは Python や Scala 、 SQL などがサポートされており、これらの言語を使用し、データを操作したり分析したりすることができます。 また、膨大な Python ライブラリ（pandas、NumPy、scikit-learn、TensorFlow、PyTorch等）をシームレスに利用することも可能で、 名寄せ 処理においては、企業がサービスとして提供しているもの以外に、 OSS として利用可能なライブラリも存在するため、それらを活用することでDatabricks上で 名寄せ 処理を実現できます。 Databricks上で 名寄せ 処理を行うメリットとして次のようなものがあります。 大量データに対して高速に実施可能 DatabricksはSpark（およびSparkを基に独自実装したPhoton）が動作するため、大量データの分散処理に強みがあります。 クラウド プラットフォームが提供する インスタンス 上に展開されるため、 インスタンス サイズを調整することで処理速度のチューニングも可能です。 Python の豊富なライブラリが利用可能 Sparkは Python や Scala で処理が記述でき、Notebookからpipによるライブラリのインストールが自由にできます。 Python はデータ分析の分野で利用実績が非常に多く、データ処理に関するライブラリ（ Unicode 正規化ライブラリなど）の豊富さは他言語と比較して突出しており、コミュニティに蓄積された豊富なノウハウを 名寄せ 処理に活用できます。 また、 API を呼び出すことも可能なため、例えば住所正規化処理を提供している外部サービスに対してリク エス トを送信し、値の正規化を行うなど、柔軟な設計が可能です。 ELT 処理のワークロード内で実現可能 Databricksでは、 Python , SQL でETLを実現できるDelta Live Tableという機能や、データパイプライン(ジョブ)を管理できるWorkflowという機能が提供されています。 これらを組み合わせることで、複数システムからのデータインポート、突合から変換、 名寄せ 処理による重複排除、アウトプット作成まで一貫して行うことができます。 3.2 テックブログで取り上げるライブラリ 「 決定論 的マッチング編」「確率的マッチング編」では実際にDatabricksで 名寄せ 処理を実装する例を紹介していきます。 名寄せ のライブラリについては 決定論 的マッチングでは「 Splink 」、確率的マッチングでは「 Zingg 」というライブラリを使用していきたいと思います。 どちらもSpark上で動作する 機械学習 を活用した 名寄せ ライブラリで、確率的マッチングを行うことができます。 （Splinkについてはルールベースの 決定論 的マッチングも実施可能なので、 決定論 マッチングの例で利用しています） 教師なし学習 によるアプローチをとるのがSplink、 教師あり学習 によるアプローチを取るのがZinggとなっています。 Splink Splinkは英 国司 法省が開発した 名寄せ ライブラリです。 教師データなし学習によるアプローチを取っており、氏名、住所、生年月日といった複数の属性情報に対し、一致・不一致を判断する信頼度による重み付けを行い、2つのレコードの一致確率を算出（≒ 名寄せ ）することができます。 「 Fellegi - Sunter 」モデルという理論に基づいて2つのレコードの一致確率を求めるのですが、その中でパラメータチューニング作業が求められるため、実装としてはやや難易度が高くなる傾向にあります。（実装には「 Fellegi - Sunter 」モデルの理解、基本的な 機械学習 の理解、そのデー タセット の理解が必要） メインとなる 名寄せ 処理（モデル作成など）以外に 名寄せ マッチングに必要な分析機能なども提供されており、 名寄せ のステップでいう対象データの分析を行う API が用意されています。 Databricksでは以前、ARC（Auto Record Linkage）というレコードの 名寄せ を行えるライブラリが提供されていました。 内容としてはSplinkをラップし、Databricks利用に特化したものだったようですが、現在更新が停止しており、利用が非推奨となっています（代わりにSplinkを直接使って欲しいと記載あり） https://www.databricks.com/blog/improving-public-sector-decision-making-simple-automated-record-linking https://github.com/databricks-industry-solutions/auto-data-linkage Zingg Zinggは、 機械学習 （ML）を活用した オープンソース の 名寄せ （エンティティ解決）ライブラリです。 顧客、製品、 サプライヤー など様々なエンティティに対応し、異なるデータソース間や単一データソース内の重複レコードや同一実体を特定・結合できます。 名寄せ 処理のステップは少しユニークで、対象となるデー タセット からまずラベリングを行い（2レコードが同一か別かを判断）、ラベリングした教師データを元にト レーニン グを行い、モデルを作成し、実際のデー タセット に対して 名寄せ を行う、といった流れを取ります。 Databricksや Snowflake 、Cassandra、S3、Azure、主要 RDBMS など、多くのデータソースやファイル形式（Parquet, Avro, JSON , CSV など）に対応しており、特にDatabricksに関しては、すぐにDatabricks上で処理を実行できるNotebookのサンプルなども提供されています。 Databricksが提供する特定の ユースケース に特化したテンプレート（ソリューション アクセラ レーターと呼ばれます）で利用されていたり、 AWS の公式ブログやHightouchのドキュメントで取り上げられるなど、（ 名寄せ ライブラリの中では ）比較的 知名度 の高いライブラリとなっています。（ GitHub stars 1k） https://www.databricks.com/jp/solutions/accelerators/product-matching-with-ml https://aws.amazon.com/jp/blogs/big-data/entity-resolution-and-fuzzy-matches-in-aws-glue-using-the-zingg-open-source-library/ https://hightouch.com/blog/what-is-entity-resolution 「Databricksで実現するデータ 名寄せ 【概要編】」については以上になります。 本記事が 名寄せ 処理を理解する上で、少しでもお役に立てれば幸いです。 「 決定論 的マッチング編」、「確率的マッチング編」では実際にDatabricks上で実装する例について紹介しますので、こちらもぜひご覧ください！ 以上、最後までご覧いただきありがとうございました。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @kumakura.koki 、レビュー： @akutsu.masahiro （ Shodo で執筆されました ）

みなさんこんにちは。 エンタープライズ 第一本部の鈴木です。 この記事では、Feature Flag（フィーチャーフラグ）を用いた開発手法についてまとめていきます。Feature Flagは昔からある開発手法の一つですが、調査する中で面白い手法だと思ったため、改めてまとめたいと思います。 1.はじめに 2.メリット/デメリット 2-1.メリット リリースサイクルとデプロイの分離 安全なデプロイ 本番環境での容易な検証と実験 2-2.デメリット コードベースの乱雑化とテスト（CI）の複雑化 未使用のFeature Flagがコードベースに残ることで、技術負債を抱える可能性がある 3.Feature Flagを用いた開発のライフサイクル 4.開発のプラクティス 未使用のFeature Flagの定期的な削除 Feature Flagの命名と整理 決定点と決定ロジックを分離する 5.まとめ 6.参考文献 1.はじめに まずはじめに、Feature Flagについて説明します。 Feature Flagとは、新たなコードをデプロイすることなく、実行時に特定の機能をオンまたはオフにするソフトウェア開発手法です。 フィーチャートグルやフィーチャースイッチなどとも呼ばれることがあります。 以下に簡単なTypeScriptの実装を掲載しています。 // app/page.tsx const featureFlag = true ; export default function Home () { return ( { featureFlag ? ( < div > < p > 🎉 新機能が有効になっています ！</ p > </ div > ) : ( < div > < p > 🚧 新機能は無効になっています 。</ p > </ div > ) } ); } このように、特定の機能やコードブロックが実行されるかどうかを条件文にして、それをフラグによってオンまたはオフを切り替えます。 この例では分かりやすいように featureFlag という変数をハードコードしていますが、通常は設定ファイルやデータベース、管理サービスなどで保持します。 上記の通り、概要自体はとても単純ですが、Feature Flagを開発に取り入れることで得られるメリットは多くあります。 次章では、Feature Flagを開発に取り入れることで得られるメリット/デメリットについてまとめます。 2.メリット/デメリット 2-1.メリット リリースサイクルとデプロイの分離 Feature Flagを採用することの１番のメリットは、リリースサイクルとデプロイの分離ができることだと思います。 Feature Flagによって、実装したコードをデプロイするタイミングと、その機能をユーザーに提供するタイミングを分離することができます。 言い換えると、機能リリースタイミングに依存せずに開発チームは任意のタイミングでコードをデプロイすることが可能になります。 デプロイの独立性が高まることで、開発チームは迅速に短いスパンでコード変更をメインブランチにマージしたり、本番環境にデプロイしたりしやすくなります。 また、ユーザーへの機能リリースは、任意のタイミングでFeature FlagをONにすることで、コードのデプロイに依存せずにリリースが可能になります。これによりリリースのタイミングとコードデプロイを合わせなくても良くなります。 安全なデプロイ Feature Flagによって安全に本番環境へデプロイすることができます。 開発者はユーザーが新しく開発した機能を利用できない状態でデプロイすることができます。 また、Feature Flagは「 キルスイッチ 」としても機能します。仮に本番環境で新機能を有効化して問題が発生した場合、問題のある機能をピンポイントで、 ロールバック なしに迅速に無効化することができます。 以上から、機能リリースのリスクを抑えつつ、安全に本番環境へデプロイすることができます。 本番環境での容易な検証と実験 Feature Flagによって本番環境を用いて、以下のような検証がしやすくなります。 ①本番環境の トラフィック やデータ量を用いた動作検証 通常、検証環境では本番同等の トラフィック やデータ量を完全に再現して検証することができないため、本番環境で予想外のインシデントが発生する可能性があります。検証用ユーザー限定でFeature Flagを有効化すれば、本番環境の トラフィック やデータ量など実運用環境でシステムを検証することができます。 ② カナリア リリースによる検証 カナリア リリースとは、新バージョンと旧バージョンのアプリケーションを並行稼働させ、新バージョンを段階的に少数のユーザーに提供し、問題がないことを確認してから全体にリリースする手法です。炭鉱で カナリア を用いて有毒ガスを検知していたことに由来します。 一部のユーザーでのみFeature Flagを有効化してリリースすることで、新機能のリリースの影響が全ユーザーに及ぶリスクを回避しながらリリースすることができます。 仮に問題が発生した場合は、Feature Flagを無効にすることで迅速に ロールバック が可能となります。また、リリース後に問題が発生しない場合は、Feature Flagを有効にするユーザーの割合を増やすことで比較的安全に全体へのリリースが可能となります。 ③A/Bテストによる検証 Feature Flagによって、本番環境で新機能と既存機能を比較し、データに基づいて意思決定を行うことができます。 例えば、ユーザーの半分は新機能を有効化し、残りは無効化にします。そして本番環境で特定のメトリクス（アプリの使用率、コンバージョン率など）やユーザーフィードバックを収集します。それらを分析して、新機能を完全にリリースするか、改善するか、削除するかなど、実データに基づいた精度の高い意思決定をすることができます。 2-2.デメリット コードベースの乱雑化とテスト（CI）の複雑化 Feature Flagを採用すると、条件分岐（if文）の実装が増えることになります。 これによってコードベースが乱雑になり、冗長な実装となり得ます。 また、条件分岐が増えることでテスト（CI）の複雑性が高まります。単純に新機能と旧機能（もしくは新機能がない状態）をそれぞれ検証する必要が生じます。複数のFeature Flag同士で依存関係がある場合は、テストケース数が指数関数的に増加するため、設計時に注意する必要があります。 未使用のFeature Flagがコードベースに残ることで、技術負債を抱える可能性がある Feature Flagの実装でコードベース上に不要なコードが残ることにより、技術負債を抱えることがあります。 適切にFeature Flagが管理されて、検証後にはきちんと削除すれば問題はありません。しかし、検証期間が長期にわたったり、削除漏れがたびたび起こったりすると不要なコードが残り続けることになります。 3.Feature Flagを用いた開発のライフサイクル Feature Flagを用いた開発のライフサイクルの一例は以下のとおりです。 Feature Flagを含む機能実装・検証 コードベースでFeature Flagを定義して、機能を実装する。 Feature Flagを定義ファイルや管理システムに設定する。 検証環境などで動作検証する。 本番環境へデプロイ、Feature Flagの有効化 開発したコードを本番環境にデプロイする。 任意のタイミングでFeature Flagを有効化して機能をリリースする。この時、リリース戦略に合わせて新機能を有効にするユーザーの割合やターゲットグループを設定する。 動作やパフォーマンスの検証 新機能の動作に問題がないことを確認する。 主要な指標（コンバージョン率、ユーザーエンゲージメントなど）や、ユーザーからのフィードバックを収集する。収集した情報を分析することで、実装した機能を完全にリリースするか改善するかの判断材料にする。 Feature Flagの削除 機能が完全にリリースされたり、廃止されたりした場合、技術負債を防ぐためにFeature Flagを削除する。 コードベースのみでなく設定ファイルや管理システムからも削除する。 4.開発のプ ラク ティス Feature Flagを開発に導入する際、以下の点に気をつける必要があります。 未使用のFeature Flagの定期的な削除 「2.メリット/デメリット > 2-2.デメリット」に記載したとおり、Feature Flagを削除しないでコードベースに残したままにすると、技術負債を抱え続けることになります。 対策としては、以下が考えられます。 機能実装の バックログ に「Feature Flagの削除」を含める。 Feature Flagに有効期限を持たせる。例えば少し乱暴ではあるが、期限切れのFeature Flagを用いたCIは失敗するように設定するなどが考えられる。 Feature Flagの 命名 と整理 ファイル名やクラス名などと同様に、Feature Flagにも一貫した 命名規則 を確立しておくことが重要です。 曖昧な 命名 をしたFeature Flagが乱立すると、何の機能に対するフラグかわからなくなります。結果的にリリース時の設定ミスにより意図しない機能が有効化されてしまったり、不要なFeature Flagがコードベースに残ってしまったりすることが考えられます。 各フラグについて、一貫した 命名 で、目的と想定動作を文書化して管理しておくことが重要です。 決定点と決定ロジックを分離する 少し実装寄りの話になりますが、Feature Flagによる機能の有効/無効をチェックする場所（決定点）と、Feature Flagの状態を決定する場所（決定ロジック）を分離するのが良いとされています。 例えば以下の実装を見てみましょう。 // featureFlags.ts （決定ロジック） export type FeatureFlagName = "isNewFeature1Enabled" | "isNewFeature2Enabled"; type FeatureFlagStates = Record<FeatureFlagName, boolean>; // 例: 設定ファイルやAppConfigのような管理サービスなどから取得した値 const featureFlagConfig: FeatureFlagStates = { isNewFeature1Enabled: true, isNewFeature2Enabled: false, }; // 決定ロジック export function isFeatureEnabled(flag: FeatureFlagName): boolean { // 引数で指定されるフラグ名に設定されたBoolean型を返却する。 return featureFlagConfig[flag]; } // app/page.tsx（決定点） import { isFeatureEnabled } from "./featureFlags" ; export default function Home () { return ( { isFeatureEnabled ( "isNewFeature1Enabled" ) && ( < div > 🎉 新機能1が有効です </ div > ) } { isFeatureEnabled ( "isNewFeature2Enabled" ) && ( < div > 🎉 新機能2が有効です </ div > ) } ); } このように決定点と決定ロジックを分離することで以下のメリットがあります。 ①メンテナンス性が向上する。 決定点と決定ロジックを分離することで、フラグの判定基準が変わってもフラグの利用箇所を修正する必要がありません。 そのため、フラグの利用箇所を探して一律変更する必要がなく、決定ロジックのみ修正すれば良くなります。 ②テストが容易になる。 決定点と決定ロジックを分離することで、それぞれ単体でのテストが可能となります。 仮に決定点と決定ロジックが同時に記述されていた場合、テストケースが複雑になり、ロジック変更の際に ソースコード やテストケースの修正に労力がかかります。そのため デザインパターン の「依存性の注入」の原則の通り、決定点と決定ロジックは分離して管理するのが良いと考えられます。 5.まとめ 今回はFeature Flagについて、概要からメリット・デメリット、そして開発に取り入れる際のプ ラク ティスをまとめました。 Feature Flagについて調査する前は、単に「if文で新機能を有効/無効にするだけでしょう」と雑に理解していましたが、いざ調べると多くのメリットがあることがわかりました。 特に、リリースサイクルとデプロイの分離が実現できることはとても魅力的と感じました。 一方で実際にプロジェクトに導入する場合は、開発サイクルの改善やプロジェクト内の教育など、それなりの労力がかかります。そのため、プロジェクトに導入したときのメリット・デメリットをきちんと整理したうえで判断していくのが大切だと思いました。 この記事には載せていませんが、理解を深めるためFeature Flagを利用したデモアプリを構築してみました。 今後記事にまとめる予定のため、興味がある方はそちらも読んでいただけるとありがたいです！最後まで読んでいただきありがとうございました。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 6.参考文献 What are feature flags? - optimizely.com How to Use Feature Flags in Azure DevOps for Seamless Feature Management - www.featbit.co Feature Toggles (aka Feature Flags) 執筆： @suzuki.takuma 、レビュー： @handa.kenta （ Shodo で執筆されました ）

はじめに こんにちは、クロス イノベーション 本部エンジニアリングテク ノロ ジー センターの徳山です。 この記事は、2025年5月 20日 に公開されたばかりの Terraform MCP Server を GitHub Copilot in VS Code ( 以降、Copilotと記載 ) で使用してみた体験談です。Terraform MCP Server の導入前のコード生成状況から導入内容、導入後のコード生成結果までを紹介します。 Terraform MCP Server は、 LLM (大規模 言語モデル ) の AIエージェントへ Terraform のプロバイダーとモジュールの検出やプロバイダーのリソース詳細情報取得などの機能を提供する MCP サーバです。 Terraform MCP Server の導入前の Copilot は、Terraform の AzureRM には存在しない架空のプロパティを提案してきていましたが、導入後はシャキッと AzureRM にもとづくコードを提案してくれるようになりました。 1. Terraform MCP Server 導入前 Copilotへの依頼内容 Copilot に今回依頼する内容は、こちらの azurerm_logic_app_workflow のサンプルコードへワークフロー定義を追加してもらいたいというものです。 サンプルコード Copilot へ依頼した結果 ( Terraform MCP Serverがないとき ) Copilot へ依頼すると以下のコードが提案されましたが、 definition というプロパティは terraform の AzureRM に存在しないためにコード上でエラーになっています。 提案されたコード エラー内容 2. Terraform MCP Server を導入 Terraform MCP Serverは、先日2025年5月 20日 にHashicopから公開された MCP サーバです。 今回は Building the Docker Image locally にしたがって Docker Image で導入しました。 導入手順の make docker-build の後、 VS Code で mcp . json へ以下のとおり記載し、 MCP サーバが停止していれば起動します。 mcp . json Terraform MCP Server 起動 Copilot Chat を開いて Agentモードで Tools を確認した結果は以下のとおりで、Terraform MCP Serverが利用できる状態であることを確認できます。 Agent Tools (一覧の下の方がTerraform MCP Server) 3. Terraform MCP Server 導入後 azurerm_logic_app_workflow のサンプルコードへのワークフロー定義の追加を再度依頼しましたが、導入後でも導入前と同等のコードを再び提案してくるため、少しプロンプトを工夫して Copilot に AzureRM を参照してもらうようにしました。 依頼した際に Copilot が resolveProviderDocID や getProviderDocs の使用許可を求めてきてくれたら許可し、それで terraform の AzureRM を参照してくれるようになりました。 当記事の作成にあたって何度かプロンプトを試した中では、「terraformの公式情報を参照して」や「AzureRMの情報を参照して」などと具体的な条件を Copilot へ示すと話が早いように思います。 導入後に依頼1 : 別の Tools をまだ使用して期待とは異なる回答 導入後の依頼2 : Terraform MCP Server の resolveProviderDocID や getProviderDocs を使用し始めてコード生成 実際に生成されたコード ( Terraform MCP Server があるとき ) resource "azurerm_logic_app_workflow" "daily_trigger" { name = "daily-trigger-workflow" location = azurerm_resource_group.eode_datapf.location resource_group_name = azurerm_resource_group.eode_datapf.name workflow_schema = "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#" workflow_parameters = jsonencode({ "definition" = { "triggers" = { "Recurrence" = { "type" = "Recurrence" "recurrence" = { "frequency" = "Day" "interval" = 1 "startTime" = "2025-05-22T01:00:00Z" } } } "actions" = { "Trigger_Container_App_Job" = { "type" = "Http" "inputs" = { "method" = "POST" "uri" = azurerm_container_app_job.generate_tpcds_refresh_data.manual_trigger_url "headers" = { "Content-Type" = "application/json" } } } } "contentVersion" = "1.0.0.0" } }) } 上記の生成されたコードでは、コード上のエラーは発生していません。 このまま terraform apply するとエラーになってしまう内容ではありますが、存在しないプロパティを生成してくることはひとまずなくなりました。 さいごに Terraform MCP Server を導入することで GitHub Copilot の生成内容の精度向上を体験できました。 導入後も導入前と同様に definition という間違ったプロパティを提案することがあるのですが、これは GitHub Copilot for Azure の Tools を使用してAzureの公式ドキュメントを参照している影響と推察しています。 根拠は、Copilot の稼働時に @azure get code gen best practices という GitHub Copilot for Azure の Tools を利用しているログが確認できることと、 Azure公式情報のこちらのページ のとおり Azure Logic Apps のワークフロー定義には definition が存在しているためです。 当然のことではありますが、目的や用途に応じて MCP サーバや Agent の Tools を適切に選別して切り替えることが重要であるとあらためて感じました。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 執筆： @shikarashika 、レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

こんにちは。コーポレート本部 サイバーセキュリティ推進部の耿です。 2025年3月に tj-actions や reviewdog など有名な サードパーティ アクションを巻き込んだ サプライチェーン 攻撃が発生しました。 GitHub や GitHub Actions の仕様を熟知したうえで悪用した、非常に巧妙な攻撃手法です。 （ 詳細 ） GitHub Actions の action の利用は、自組織の GitHub リポジトリ で第 三者 が書いたコードの実行を許すことに他なりません。その便利さと引き換えに一定のセキュリティリスクを孕んでいることを意識し、正しく対策を考えることが重要です。 今回発生したような侵害への防止策として、 GitHub Actions の action を利用する場合のバージョン指定はバージョンタグではなく、フルコミットハッシュ（SHA）を利用して「ピン留め」すること（ 参考 ）が、より一層推奨されるようになっています。Gitのコミットハッシュは、 リポジトリ 内のオブジェクトを階層的に SHA-1 ハッシュ化したものなので、コードが書き換わるとコミットハッシュも勝手に変わります。つまりコミットハッシュでバージョン指定することにより、実行されるコードを事実上固定することができます。 しかし、コミットハッシュによるバージョン指定だけで話を終えるのは不十分です。運用まで考えたときに、コミットハッシュで指定したバージョンの更新方法にも気を配らないと、全くリスク低減にならない可能性があります。 GitHub Actions の action をバージョン更新する際の運用負荷とセキュリティリスク低減のバランスについて考えてみます。 （おさらい）フルコミットハッシュ（SHA）によるバージョン指定 バージョン更新の課題 解決策１：セキュリティアップデート以外は更新を自動化しない 解決策２：セキュリティアップデート以外は自動更新を一定期間待機する 自動更新の待機期間をどれぐらいにするべきなのか？ （おさらい）フルコミットハッシュ（SHA）によるバージョン指定 様々なところで言われていることなので詳細は省きますが、 GitHub Actions の action に付けられたGitタグは書き換え可能なので、バージョンタグでバージョン指定すると、実行されるコードは可変です。 ❌ - uses : actions/checkout@v4 アクションのREADMEや技術記事などでバージョンタグによる例が記載されていても、自分で利用するときにはフルコミットハッシュに書き換えるようにしましょう。 ✅ - uses : actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 バージョン更新の課題 フルコミットハッシュでバージョン指定をしても解決されない課題があります。どのようにバージョン更新を行うかという課題です。 特に多くの GitHub Actions の action を使っている場合や、多くの リポジトリ を管理している場合は、バージョンの更新を手作業で実施するのは手間がかかります。手間を減らすために、Dependabot や Renovate を利用して更新を自動化することがよく行われています。（Dependabot と Renovate は、フルコミットハッシュでバージョン指定していても更新のPRを作成できます。） ここで留意しておきたいのは、更新を自動化することにより、 新しいバージョンが侵害されていた場合には影響を受けやすくなってしまう ということです。今回 tj-actions/changed-files が侵害を受けた件でも、バージョンタグが（悪意のあるコミットを指すように）更新されたことを検知し、多くの リポジトリ で動いている Renovate がバージョン更新の PR を出していました（ 参考 ）。さらに、 GitHub Actions のワークフローでよく使われる push の イベントトリガー では、更新されたブランチ（つまり更新された新しいバージョン）のワークフローファイルが実行されます。つまり自動作成された PR をマージせずとも、PR が自動作成されただけで侵害されたバージョンが自分の リポジトリ 上で実行される可能性があるということです。 まとめると、以下の攻撃が成立し得ます： 利用している GitHub Actions の action が侵害され、リリースされる。あるいは更新された新しいバージョンに 脆弱性 が含まれる DependabotやRenovateがバージョン更新を検知し、PRを作る push イベントをトリガーに実行されるワークフローでは新しいバージョン（侵害されたバージョン or 脆弱性 のあるバージョン）の GitHub Actions の action が実行する 自分の リポジトリ が被害を受ける GitHub Actions の action の更新の自動化には気を遣わなければならないと考えています。 解決策１：セキュリティアップデート以外は更新を自動化しない 自動化せずにアップデートを手作業で行えばリスクは低減できますが、運用負荷が上がってしまいます。 特に GitHub Actions のセキュリティアップデートを自動化しない場合、対応までの時間が伸びてしまいます。 両者のバランスを考えたときに、（一定のセキュリティリスクが発生することを承知の上で）「セキュリティアップデートのみを自動化し、それ以外のアップデートは自動化しない」方針が考えられます。 セキュリティアップデートのみの自動化は次の方法で実現できます。 Dependabotの場合 Dependabot Version UpdatesではなくDependabot Security Updatesを利用する Renovateの場合 脆弱性 のみ自動更新するように設定する（ 参考 ） セキュリティアップデート以外を自動化せずに更新する部分については、完全に手作業でコミットハッシュをコピー&ペーストしていくのは大変なので、ローカルツールの pinact などでコミットハッシュを更新するのも良いでしょう。 解決策２：セキュリティアップデート以外は自動更新を一定期間待機する Renovateには、セキュリティアップデート以外の更新をすぐにせずに指定期間待機してからPRを作成する機能があります。一定期間待機することで、その間に攻撃や 脆弱性 が検知・解決されることを期待するという考え方です。 Renovateの場合： minimumReleaseAge パラメータ https://docs.renovatebot.com/configuration-options/#minimumreleaseage Dependabot Version Updatesにも、最近のアップデートで同じような機能がベータ版として出ています。ただし現時点ではまだ GitHub Actionsはサポートされていないようです。使えるようになったら試してみたいと思います。 Dependabotの場合：cooldown パラメータ（今後に期待） https://github.com/dependabot/dependabot-core/issues/3651 （2025/7/10追記）Dependabotのcooldownパラメータが正式リリースされましたので、 解説記事 を公開しました。 自動更新の待機期間をどれぐらいにするべきなのか？ これは答えが出ない問題です。 GitHub Actions の action による悪さを「100%」回避するには次のどちらかしかないと思っています。 GitHub Actions の action をそもそも利用しない GitHub の公式 action（ actions/checkout など）が侵害されるリスクも考慮し、利用しないとすると、「 GitHub ActionsによるCI/CDを実施しない」こととほぼ同義になると思います GitHub Actions の action のバージョン更新をするときに「コードの内容を全て読み」、「動きを完全に理解」したうえで更新する このどちらも現実的ではないのは明らかです。 GitHub Actions の action を利用することの便利さを享受するには、一定のリスクを受容するしかないと考えています。待機期間の判断も同じです。今回の侵害の件では tj-actions に対する侵害は数日で対応されましたが、 reviewdog に対する侵害の対応には1週間以上かかったようです。どれぐらいの期間を置けば侵害や 脆弱性 が検知され、受容できる程度までリスクが低減するかは程度問題でしかありません。 リポジトリ の重要度と運用の手間で判断することになるでしょう。 それでもあえて個人的な考えを述べるならば、1週間程度は少なくとも待ちたい気持ちがあります。（根拠はなく、ただの個人的な感覚であることを強調しておきます。） お読みいただきありがとうございました。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 執筆： @kou.kinyo 、レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

初めまして。エンタプライズ第一本部の佐藤です。 前回は MCP サーバーの立ち上げ方の記事を作成しましたが、今回はこのサーバーに接続するClientを用いて接続側の実装をするという試みです。 前回記事はこちら 【初心者向け】2年目エンジニアが実践したMCPサーバー構築ガイド2025 既出の内容かつ不正確な部分もあるかもしれませんが、私の個人的な検証記録として残しておきたいという目的でこの記事を作成します。 最近 MCP サーバーが盛り上がってますが、サーバーへ接続する方法も知りたかったので本記事を作成します。 前回の記事では以下の図の赤枠の部分を実装しました。 上側の水色の矢印部分にあたるツール呼び出し部はClaudeDesktopに内包されていたので、前回はこの部分のロジックを意識せずにツールを実行できるかという部分を検証していました。 さて、ClaudeDesktopから呼び出せるのも良いのですが、通信規格を統一したというところの良さを実感しつつ、なぜツールが選択できているのかを詳しく見ていきます。 では、例のごとく MCP QuickStartの For Client Developers を参考にClientの実装を行いましょう。 まずは環境構築です。 上から順に、 作業 ディレクト リの作成 仮想環境を有効化 仮想環境に必要な依存関係を追加 main.pyを削除（client.pyで作業するため） client.pyを作成 という操作をしています。 client.pyが今回、コードを作成する部分です。 # Create project directory uv init mcp-client cd mcp-client # Create virtual environment uv venv # Activate virtual environment # On Windows: .venv\Scripts\activate # On Unix or MacOS: source .venv/bin/activate # Install required packages uv add mcp anthropic python-dotenv # Remove boilerplate files rm main.py # Create our main file touch client.py 次はAnthropicの API キーを取得して.envファイルに書いておきます。 ファイルの作成 # Create .env file touch .env この.envファイルを編集して以下の記述を追加。 your key hereの部分は API キーを記載します。 API キーの取得方法はこちらで、 APIのページ に遷移して、StartBuildingを押下し、GetAPIkeysを選択します。 Create Keyを選択して、任意の名前をつけてAddを押下。 次のポップアップでキーが出るのでコピーしてください。 【注意】この API キーは厳重に保管し、使用しなくなった場合は削除をしてください。流出すると思わぬ課金の原因になります。 ANTHROPIC_API_KEY=<your key here> 次に以下のコマンドで.gitignoreにこのファイルを追加します。 構成管理に含めないことで API キーがリモートレポジトリに保存されないようにします。 echo ".env" >> .gitignore 以上で環境構築は終了です。 次にclient.py内で作業を行っていきます。 import asyncio from typing import Optional from contextlib import AsyncExitStack from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client from anthropic import Anthropic from dotenv import load_dotenv load_dotenv() # load environment variables from .env class MCPClient : def __init__ (self): # Initialize session and client objects self.session: Optional[ClientSession] = None self.exit_stack = AsyncExitStack() self.anthropic = Anthropic() async def connect_to_server (self, server_script_path: str ): """Connect to an MCP server Args: server_script_path: Path to the server script (.py or .js) """ is_python = server_script_path.endswith( '.py' ) is_js = server_script_path.endswith( '.js' ) if not (is_python or is_js): raise ValueError ( "Server script must be a .py or .js file" ) command = "python" if is_python else "node" server_params = StdioServerParameters( command=command, args=[server_script_path], env= None ) stdio_transport = await self.exit_stack.enter_async_context(stdio_client(server_params)) self.stdio, self.write = stdio_transport self.session = await self.exit_stack.enter_async_context(ClientSession(self.stdio, self.write)) await self.session.initialize() # List available tools response = await self.session.list_tools() tools = response.tools print ( " \n Connected to server with tools:" , [tool.name for tool in tools]) ここまでがサーバーとの接続を担う部分です。標準入出力を用いるようにしています。 async def process_query (self, query: str ) -> str : """Process a query using Claude and available tools""" messages = [ { "role" : "user" , "content" : query } ] response = await self.session.list_tools() available_tools = [{ "name" : tool.name, "description" : tool.description, "input_schema" : tool.inputSchema } for tool in response.tools] # Initial Claude API call response = self.anthropic.messages.create( model= "claude-3-5-sonnet-20241022" , max_tokens= 1000 , messages=messages, tools=available_tools ) ここまでで入力された質問に関する解析を行っています。 具体的には関数（ツール）の説明文と引数の型の情報をもつ使用可能なツールをLLMに渡しています。 図のようなイメージでツール情報と質問文をLLMに投げちゃってます！ # Process response and handle tool calls final_text = [] assistant_message_content = [] for content in response.content: if content.type == 'text' : final_text.append(content.text) assistant_message_content.append(content) elif content.type == 'tool_use' : tool_name = content.name tool_args = content.input # Execute tool call result = await self.session.call_tool(tool_name, tool_args) final_text.append(f "[Calling tool {tool_name} with args {tool_args}]" ) この部分でさっき使えるツール情報と質問文を投げた結果を用いています。 イメージは以下の図で天気の質問なら、天気取得ツールを使った方が良いですねとなっているということです。 ここでresultに使用すべきツールとして”use_tool”フラグがついた関数を呼び出した結果を格納し、LLMに渡すメッセージの一部として格納しています。 assistant_message_content.append(content) messages.append({ "role" : "assistant" , "content" : assistant_message_content }) messages.append({ "role" : "user" , "content" : [ { "type" : "tool_result" , "tool_use_id" : content.id, "content" : result.content } ] }) # Get next response from Claude response = self.anthropic.messages.create( model= "claude-3-5-sonnet-20241022" , max_tokens= 1000 , messages=messages, tools=available_tools ) final_text.append(response.content[ 0 ].text) return " \n " .join(final_text) ここで最初の質問文である「今日の天気は？」と利用した天気取得ツールからのレスポンス「晴れ」を用いて、回答を出力します。 イメージは以下の図の通りです。 ここまでで、LLMへのリク エス トは2回しています。 まとめると、1つのツールを呼びだすにはツールの判定、質問文と結果のセットで回答生成というプロセスを背後で行うということです。 async def chat_loop (self): """Run an interactive chat loop""" print ( " \n MCP Client Started!" ) print ( "Type your queries or 'quit' to exit." ) while True : try : query = input ( " \n Query: " ).strip() if query.lower() == 'quit' : break response = await self.process_query(query) print ( " \n " + response) except Exception as e: print (f " \n Error: {str(e)}" ) async def cleanup (self): """Clean up resources""" await self.exit_stack.aclose() async def main (): if len (sys.argv) < 2 : print ( "Usage: python client.py <path_to_server_script>" ) sys.exit( 1 ) client = MCPClient() try : await client.connect_to_server(sys.argv[ 1 ]) await client.chat_loop() finally : await client.cleanup() if __name__ == "__main__" : import sys asyncio.run(main()) 最後に、先ほどの回答生成プロセスの実体であるprocess_query関数で回答を生成するようにしています。 これでサーバーを起動する側の準備が整いました。 前回の続きでサーバーを立てていればweather.pyが利用できるはずなので、こちらを指定してclient.pyでweather.pyを起動します。 #pathは自分の環境に設定してください uv run client.py path/to/weather.py このコマンドを実行すると、以下のようにコンソールでLLMを使用でき、 MCP サーバーにも接続できています。 実際に使用可能なツールとして、add、get_alerts、get_forecastの3つが表示されました。 Queryの後に「 サクラメント の天気は？」のように適当な指示文を渡すと回答が生成されます。 この検証を応用してインタフェースを変えることもできそうですね！ 以上で作業を終わります。 ここまで読んでくださり、ありがとうございました！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @sato.yu 、レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

はじめに 初めまして。 エンタープライズ 第一本部、2年目の佐藤悠です。 Datadogは様々な環境でのモニタリングが可能で、監視対象の統合に向いておりオンプレミスと クラウド 環境のハイブリッドの場合や複数 クラウド の組み合わせなど、インテグレーションの多様さで柔軟に対応できるのが強みであると思います。 個人的には使いやすくて、デザインが好きなので気に入っています。 この記事ではAmazonLinuxのマシンイメージを使用したEC2 インスタンス のメトリクスを、手順のスクショや図解をもとに ダッシュ ボードに表示するところまで実施します。 作業手順 無料トライアルを開始します。 以下のサイトにアクセスし、画面中央にある無料トライアルボタンを押下します。 https://www.datadoghq.com/ 以下の画面で必要事項の入力が求められるので、これを埋めます。 一応、リージョンが日本になっていることを確認してください。 入力後サインアップのボタンを押下することで以下のアンケートの画面に遷移します。 全て任意の内容なので実施はお任せします。画面下部までスクロールしNextのボタンを押下します。 遷移先では以下の画面になります。 今回は AWS 上のマシンイメージがAmazonLinuxのEC2 インスタンス を立ち上げて監視対象にします。 左側の Linux を選択して、コマンドをコピーしておきます。 では、 AWS でEC2を立ち上げます。 今回はコマンドをEC2上で実行する必要があるので、セッションマネージャー（以降：SSM）でEC2に接続する設定も同時に行います。 インスタンス 名などは任意のものを使用しますが、OSに関しては指定します。 インスタンス タイプもデモなので最も小さいサイズのものにしています。 ネットワーク設定はSSMを使用するため、アウトバウンドの443ポートを許可しています。 Datadogの ネットワークトラフィック の資料を参考にするとAgentを使用する ユースケース に限定すれば、アウトバウンドの443ポートの解放のみで動作します。 ネットワーク設定に関する詳細はリンク先の資料をご確認ください。 次に、以下の部分の高度な設定を編集して、SSMに必要なロールを持つ インスタンス プロファイルをアタッチします。 ない場合には赤枠の部分から作成します。 遷移先の画面でロールの作成を押下して以下の画面に遷移します。 ラジオボタン で ユースケース を選択して、System Manager用のロールを作成出来ればOKです。 ここで任意のロール名をつけて先ほどのEC2 インスタンス の画面で インスタンス プロフィールに作成したものを選択すれば、準備完了です。 プロフィールが表示されない場合は少し時間をあけてリロードボタンを押下すれば出ます。 インスタンス が立ち上がったことを確認し、作成した インスタンス IDを押下し、 インスタンス 概要の画面で右上の接続ボタンを押下します。 タブの切り替えでセッションマネージャーを選択し、接続を押下します。 （接続ボタンがグレーになっているときは、ネットワークの設定、ロール、またはポリシーの設定ができていない場合が多いです） インスタンス に接続後は CUI の画面で先ほどのDatadogで表示されていたコマンドを実行します。 このままコピー&ペーストして実行でOKです。 これでDatadogのエージェントがEC2 インスタンス にインストールできました。 現時点での構成を図にして解説します。 今回はデモなので図のような構成になっています。 実際にはEC2をプライベートサブネットに配置し、NAT ゲートウェイ を使用して外部と通信するのが望ましいですが、コストの関係で実施していません。 では、Datadog画面左下のIntegrationsにカーソルを合わせ赤枠のView Agentsを押下して実際にデータが取得できているかを確認しましょう。 遷移先でView Agentsを選択し表示を見ると以下のとおりでAgentをインストールしたEC2 インスタンス がDataDogと接続できていることが確認できました。 以下の画像で考えると インスタンス IDがHOSTNAMEと一致しているかで確認できます。 次に画面左側のツールの赤枠、Infrastructureを押下します。 ここで遷移した先に、監視対象のEC2 インスタンス が表示されています。 右赤枠のどこでもいいので押下すると詳細な表示を確認することができます。 表示される インスタンス に関する詳しいメトリクスは以下のようになっています。 ここで取得した内容を ダッシュ ボードに表示します。 これは環境ごとの ダッシュ ボードを作成し、一元管理することによって見通しが良くなることが期待できます。 以下の画像のように、開発・ STG ・PRODのように分離することが実際の運用ではありそうですね。 では実際に作成します。 左側ツール赤枠にカーソルを合わせNew Dashboard を押下します。 以下の表示で名前と Dashboard の概観を決定します。 以下の画面に遷移したら右側上赤枠の検索窓でHOSTと検索し、右下赤枠のHosts Overviewを押下します。 以下の画面で左側赤枠のPowerpack filtersで先ほどのhostを選択します。 右下のconfirmを押下して Dashboard の ウィジェット に追加します。 画面のようにモニタリング内容を Dashboard に追加することができました。 モニタリングしているCPUの使用率を高めて、画面に反映されるか確認します。 EC2 インスタンス に接続して以下のコマンドを実行します。 sudo yum install stress stress -c 1 CPUに負荷をかけるstressをインストールして、実際にCPUに負荷をかけます。 この結果がすぐにモニターに反映されUsageが上昇しました。 これでEC2 AmazonLinuxを監視し、選択した内容を ダッシュ ボードに追加することができましたね！ まとめ 複雑化し続ける クラウド アーキテクチャ ーをDatadogで一元管理！ 14日間はホスト数に制限はありますが、全ての機能が無料で使えます。 以降は機能に制限はかかりますが検証用には使えるのでありがたいですね！ 無料期間のスタート ダッシュ に本記事を参考にしていただければ幸いです。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @sato.yu 、レビュー： @yamada.y （ Shodo で執筆されました ）

こんにちは。金融IT本部　 経営管理 ソリューション部の藤樫です。 現在、金融機関への ERP パッケージの新規導入案件に携わっています。 私は2023年10月に 電通 総研（旧ISID）へ中途入社し、ちょうど1年半が経過しました。 今回は転職の経緯や入社して感じたことをお話したいと思います。 転職活動について 前職はユーザー系 SIer 企業で、 ERP の保守を担当していました。 IT系の業界や仕事が好きで、転職後も ERP を用いた システム開発 に携わりたい、という想いがあったため 同業で ERP を扱っている募集に絞り、転職活動を開始しました。 初めて面接を受けた企業が 電通 総研だったのですが、面接が対話形式で進んだのが驚きでした。 （もっとお堅い場を想像していました） 人事の方をはじめ、現場の方から役職の方までとてもフランクに接してくださり ユーモアを交えながら進めてくださったのが好印象でした。 入社の決め手 社員の皆さんの人柄が1番の決め手となりました。 また面接で経歴だけでなく、人となりまで見た上で選考していただいたこと、 内定承諾前にカジュアル面談をしていただき、最後までフォローが手厚かったことも良かった点でした。 選考の過程で、 電通 総研の皆さんと一緒に働きたいという想いが強くなり、 電通 総研への入社を決めました。 入社前に不安だったこと ①業界の違い 学生時代は情報系の専攻で、前職は電力業界であったため、金融業界は初めてでした。 そのため業界知識のキャッチアップから始める必要がありました。 ②製品の違い 前職はSAPを扱っており、今扱っている Oracle ERP Cloudは初めてでした。 同じ ERP でも製品が違うと思想や仕組みが全く異なるため、これもまた0からの勉強が必要であり ちゃんと貢献できるようになるのか不安を感じていました。 ③職種の違い 前職では親会社の保守業務を担当していたため、新規導入案件には携わったことがありませんでした。 システム開発 のフローは机上の知識しかなく、実務は経験がないため、前述の①②に加え さらに不安となる要素の1つでした。 入社後のギャップ 選考中のフォローがかなり手厚かったため、ギャップはほとんどありませんでした。 前述の入社前の不安事項も、部の皆さんのサポートのおかげで、徐々に解消されました。 1つ挙げるとすれば、“働きやすさ”です。 これはいい意味でのギャップなのですが、想像以上に働きやすい環境であると感じています。 詳細は後述の「現在の働き方」でお話します。 入社前後における環境の変化 転職を機に初めて上京したため、職場だけでなく、居住環境も大きく変わりました。 住むエリアを決める際、入社前にも関わらず、部の皆さんがアド バイス してくださったおかげで 通勤時間や住みやすさを考慮した、納得のいく部屋に住むことができ、無事東京生活をスタートすることができました。 また勤務スタイルにも変化がありました。前職は全員が同じ拠点に出社し毎日顔を合わせて働いていましたが、 現在は、各自が 臨機応変 に出社勤務と在宅勤務を選択できます。 またお客様先への移動の前後などは、サテライトシェアオフィスでの勤務も認められています。 働きやすい反面、顔を合わせる機会が少ないため、最初は部や仕事に馴染めるのかとても不安でした。 ただ入社後も、部員全員との1on1や、全員と対面できるようランチ会を複数回企画していただく等 コミュニケーションを取りやすくするための、様々な工夫をしていただきました。 そのため環境には割と早い段階で慣れることができたと感じています。 会社や事業部でも、中途入社者・女性社員・若手社員の座談会があったりと コミュニティが多数あるため、中途入社でも人脈を広げやすい環境かと思います。 現在の働き方 普段は、基本的に案件業務を行っており、これまで要件定義～テスト工程まで携わってきました。 具体的には、お客様との仕様の合意形成や設計業務・開発チームの取りまとめ等を実施しています。 特に、ユーザーと直接やり取りできるポジションに憧れていたので、 電通 総研に入社して 希望の業務に従事することができ、やりがいや充実感を持って仕事ができています。 案件以外では、このような記事の執筆作業だったり、新人の OJT ・中途入社者のフォロー等を行っています。 勤務場所は、前述の通り選択肢が幅広く、自宅・ サテライトオフィス ・お客様先等、 仕事内容や体調に合わせて柔軟に選択可能で、メリハリをつけて働くことができています。 長期休暇のタイミングでは、ワーケーション勤務制度を活用し、地方にある実家からリモートワークをすることもあります。 忙しい時でも公私ともに充実させることができるため、とても働きやすい環境であると感じています。 デスクワークで 疲労 が溜まった時には、社内のマッサージルームを利用し、凝りの解消や息抜きをしています。 （社員価格で格安なので、すごくオススメです） またプライベートの話になりますが、ディズニーが好きなので グッズを買ったりパークへ行ったりすることを楽しみに、日々励んでいます。 最後に ここまで読んでいただきありがとうございました！ 電通 総研では、新卒・キャリア採用問わず共に働いてくれる仲間を募集しています。 私の所属する部は、中途社員と新卒社員が半々で、女性も半数近くいます。 また経験値や年次に関わらず、やりたいことが実現できる環境が整っています。 もし 電通 総研にご興味があれば、応募をご検討いただければと思います！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @togashi.ayana 、レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

こんにちは、クロス イノベーション 本部エンジニアリングテク ノロ ジー センターの小澤英泰です。 本記事では GitHub Codespacesを活用する中で学んだ、複数のDev Containerの設定がある リポジトリ において、起動するDev Containerを指定する方法を紹介します。 はじめに 複数のDev Containerの設定方法 ローカルマシンでのDev Containerの起動 GitHub CodespacesでのDev Containerの起動 Default Codespaces configration とは？ 問題 解決策1 解決策2 さいごに はじめに 前提知識となるDev Containerや GitHub Codespacesの概要は本記事では省略します。 適宜、過去に弊社社員が発表の記事や動画を参照してください。 テックブログ：GitHub Codespace を使った開発環境のメリットをまとめてみた TECH PLAY の記事：開発効率向上・フレキシブルな働き方・セキュリティの確保──ストレスフリーな開発体験を「GitHub Codespaces」で実現するポイント解説 TECH PLAY のアーカイブ動画：開発効率向上も、フレキシブルな働き方も、セキュリティの確保も、GitHub Codespacesで実現！-ストレスフリーな開発体験のカギ- 複数のDev Containerの設定方法 複数のDev Containerを設定するには、 リポジトリ の .devcontainer 配下はどのような ディレクト リ構成になるでしょうか。 例えば、 VSCode のドキュメント Connect to multiple containers では、下記の構成を採っています。 📁 project-root 📁 .git 📁 .devcontainer 📁 python-container 📄 devcontainer.json 📁 node-container 📄 devcontainer.json 📁 python-src 📄 hello.py 📁 node-src 📄 hello.js 📄 docker-compose.yml .devcontainer 配下に設定ごとの ディレクト リ python-container と node-container を作成し devcontainer.json を置いています。 上記の構成にならって、複数のDev Containerの設定をしました。 . ├── .devcontainer ├── DevContainerA │ └── devcontainer.json └── DevContainerB └── devcontainer.json .devcontainer/DevContainerA/devcontainer.json の中身 { " name ": " DevContainerA ", " image ": " mcr.microsoft.com/devcontainers/base:ubuntu " } .devcontainer/DevContainerB/devcontainer.json の中身 { " name ": " DevContainerB ", " image ": " mcr.microsoft.com/devcontainers/base:ubuntu " } それではローカルマシンと GitHub Codespaces上の2つのパターンでDev Containerの起動方法を確認しましょう。 ローカルマシンでのDev Containerの起動 ローカルマシンでのDev Containerの起動手順を確認します。 VSCode の コンテナーで再度開く を選択すると、設定したDev Containerの一覧が表示され、起動対象のDev Containerを選べます。 GitHub CodespacesでのDev Containerの起動 GitHub CodespacesでのDev Containerの起動手順を確認します。 VSCode の Create New Codespace... を選択後、起動対象のブランチを選択すると、Dev Containerの一覧が表示されます。 ローカルマシンの場合と異なり、 GitHub Codespacesの場合は、一番上に Default Codespaces configration が表示されています。Default Codespaces configrationとは、一体何者なのでしょうか。 Default Codespaces configration とは？ Default Codespaces configration を日本語では 既定の開発コンテナー構成 と呼びます。 既定の開発コンテナー構成とは、 GitHub が用意したDev Containerです。下記の特徴があります。 GitHub によって既定の Linux イメージからコンテナーが作成されます。 この Linux イメージには、 Python 、Node、 PHP 、 Java 、Go、 C++ 、 Ruby 、.NET Core/ C# などの一般的な言語のランタイム バージョンが多数含まれています。 これらの言語の最新または LTS リリースが使用されます。 JupyterLab や Conda など、データ サイエンスと 機械学習 をサポートするツールもあります。 既定の開発コンテナー イメージには、Git、 GitHub CLI 、yarn、openssh、 vim などの他の開発者ツールやユーティリティも含まれています。 詳細は 既定の開発コンテナー構成の使用 を参照してください。 また、Default Codespaces configrationが表示されるのは、 .devcontainer 直下に devcontainer.json がない場合の GitHub の仕様です。 .devcontainer/devcontainer. json または .devcontainer. json が存在する場合は、codespace を作成するときに使用可能な構成ファイルの一覧でそれが既定の選択になります。 どちらのファイルも存在しない場合は、既定の開発コンテナー構成が既定で選択されます。 詳細は codespace の作成時における既定の構成の選択 を参照してください。 問題 VSCode から GitHub Codespacesを起動する場合はDev Containerの一覧が表示され起動対象のDev Containerを選べるため、一見問題はなさそうです。しかし、ブラウザの github .comから GitHub Codespacesを起動する場合に注意が必要です。 リポジトリ を開き Code をクリックし Codespacesタブ を開きます。 + ボタン または Create codespace on main をクリックすると、自動で既定の開発コンテナー構成で起動します。 起動対象のDev Containerを選ぶことはできません。 起動対象のDev Containerを選ぶには、 ･･･ ボタン から New with options... をクリックします。遷移先の画面で他のオプションも含め選択することができます。 毎回、 New with options... から起動するのは面倒です。油断して + ボタン または Create codespace on main から起動し、 npm run dev などのコマンド実行の失敗後にミスに気づき残念な気持ちにもなります。再作成には時間も費用もかかるので改善しましょう。 解決策1 ディレクト リの構成を変更します。 DevContainerA 配下の devcontainer.json を .devcontainer 直下に移動することでデフォルトのDev ContaienerをDevContainerAの設定とすることができます。 変更前の構成 . ├── .devcontainer ├── DevContainerA │ └── devcontainer.json └── DevContainerB └── devcontainer.json 変更後の構成 . ├── .devcontainer │ ├── DevContainerB │ │ └── devcontainer.json │ └── devcontainer.json 変更後はDefault Codespaces configrationが消え、デフォルトでDevContainerAが選択されます。 VSCode から起動する場合もDefault Codespaces configrationが消えています。 なお、 ディレクト リ構成を変更してもローカルマシンでのDev Containerの起動方法に影響はありません。 解決策2 ディレクト リ構成を変えない場合は、READMEに GitHub Codespaces 作成ページへのリンクを置くことで問題を回避できます。設定するURLは Share a deep link から確認できます。 Markdown タブを開くと、READMEに埋め込む値をコピーできます。 [](https://codespaces.new/Hideyasu-Ozawa/multi-dev-container) 上記コピーした値をREADMEに貼り付けると、バッジが表示されます。 バッチをクリックするとオプションを選択する画面に飛びます。 各オプションの値もクエリパラメータを変更することで簡単にカスタマイズできます。バッチに設定したURLを下記に変更します。 https://github.com/codespaces/new/Hideyasu-Ozawa/multi-dev-container?skip_quickstart=true&machine=standardLinux32gb&repo=934587189&ref=branchName&devcontainer_path=.devcontainer%2FDevContainerB%2Fdevcontainer.json&geo=UsEast) バッチをクリックすると、ブランチにbranchName、Dev ContainerにDevContainerB、RegionにUS East、Machine typeに4-coreを設定した状態で開きます。 READMEに配置したバッチから GitHub Codespacesを作成することで、Dev Containerに既定の開発コンテナー構成を使うミスを回避できるようになりました。 さいごに 本記事では、複数のDev Containerの設定がある リポジトリ において、 GitHub Codespacesで起動するDev Containerを指定する方法を紹介しました。 ローカルマシンと GitHub CodespacesでDev Containerを起動する際の仕様が異なることには注意が要りますが、解決策1の ディレクト リ構成を変更しつつ、解決策2のREADMEにリンクを置くことで、 GitHub Codespacesの起動時の体験をより良くすることができました。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @ozawa.hideyasu 、レビュー： Ishizawa Kento (@kent) （ Shodo で執筆されました ）

こんにちは。 エンタープライズ 第一本部 戦略ソリューション 1 部の英です。 普段はWebアプリや スマホ アプリの案件などを担当しています。あと、趣味でAIを勉強しています。 OpenAIから新しいCodexが発表されたのでさっそく遊んでみます。 https://help.openai.com/en/articles/11096431-openai-codex-cli-getting-started 1.環境構築 2.インストール 3.デモアプリを作る 4.デモアプリで遊んでみる 5.デモアプリで遊んでみる(再) 6.デザインを整える 7.テストコードを書かせてみる 8.テストコードを追加してみる さいごに 1.環境構築 詳細は割愛しますが、手元で以下を行ってください。 筆者の環境は Windows です。 VSCode のインストール Node.jsのインストール(npmにパスを通す) API キーを発行する(OpenAIのDeveloperページで作成できる) 2.インストール VSCode で新規のターミナルを開き、以下を実行します。 npm実行の際に、権限系で止められたら各自で追加してください。 npm install -g @openai/codex 次に以下を実行します。 codex これで動かせます。早い。 3.デモアプリを作る さて、さっそくアプリを作ってみましょう。 そうですね。 「愚痴を吐いたらAIが励ましてくれるようなサービス」なんてどうでしょうか。 ア イデア の引き出しで放置していたのですが、ここで消費してみようと思います。 Codexに以下のプロンプトを送信してみます。 Node.js + Express を使って、愚痴を投稿すると複数の仮想キャラクター（陽キャ・理系・スパルタ・癒し系）が ChatGPT API を使って日本語で励ましのコメントを返してくれるWebアプリを作ってください。UIはEJSで構築し、すべて日本語表示にしてください。 ChatGPTのAPIキーはenvファイルにセットする仕組みとしましょう。 モデルはgpt-4o-miniなんてどうでしょう？ 思考が始まりました。かわいいですね。 mkdirのコマンドを叩きたいと要求してきました。許可してみます。 実行できなくて困ってますね。かわいいですね。 すごい手前で躓いているので情報を足してみます。 package. json を作成していいかと聞かれました。「Y」で肯定しておきます。 ファイルが作られました。 次はnode_modulesの ディレクト リとenvファイルの作成を提案してきました。「Y」で肯定しておきます。 READMEの作成を提案してきました。「Y」で肯定しておきます。 やっと中身のコーディングに入りました。index.jsの提案が来ました。「Y」で肯定しておきます。 このペースでスクショを載せていると長くなりそうなので、CodeXが考えに詰まるまでスキップしますね。 4.デモアプリで遊んでみる Yを10回くらい押したらアプリができたようです。 以下は最後の出力で、このアプリの実行方法を教えてくれています。手順に従ってみます。 エラーを吐きました。もう一度Codexを開いて、この事実を伝えます。(全文コピペでOK) デバッグ 方法を考え始めました。しばらく提案を受けましょう。 「Y」を5回くらい叩くと、バグ修正が終わったみたいです。 5.デモアプリで遊んでみる(再) 再度実行するとうまく起動しました。 さっそく localhost にアクセスしてみます。 気になっていたのですが、 CSS は書いていない(そもそも命令していない)ので単純なHTMLが表示されています。 上手くいきました。 急に4人から励まされるとびっくりしますね。 ちなみに、ChatGPT API へのプロンプトは以下のように設計されていました。 const personas = [ { key: 'yo', name: '陽キャ', system: 'あなたは陽キャのキャラクターです。明るく元気な言葉でユーザーを励ましてください。' }, { key: 'rikei', name: '理系', system: 'あなたは理系のキャラクターです。論理的で落ち着いた言葉でユーザーを励ましてください。' }, { key: 'sparta', name: 'スパルタ', system: 'あなたはスパルタのキャラクターです。厳しくも的確な言葉でユーザーを励ましてください。' }, { key: 'iyashi', name: '癒し系', system: 'あなたは癒し系のキャラクターです。優しく温かい言葉でユーザーを励ましてください。' }, ]; 6.デザインを整える シンプルなHTMLだとちょっとダサすぎるので、いまっぽいデザインに書き換えてみましょう。 デザイン修正だけなのに「Y」を10回くらい叩かされました。 以下に理由を書いていますが、CodeXに文脈を伝えるのが少し面倒でした。 この辺は GitHub Copilotの方が操作性は高いと感じます。 7.テストコードを書かせてみる 自動生成の ソースコード はテストコードとセットで作成するべきだと個人的には考えています。 今回もテストコードを書かせてみます。 先ほどの CSS の作成の時もそうでしたが、CodeXが現状を把握をするのにすごく時間がかかります。 以下のプロンプトはかなり有効だったのでお試しあれ。 テストコードが提案されました。 テストに実行方法も記載してくれているので実行してみます。 コケました。 Codexに伝えて、原因を探ります。 修正が完了したため、再テストしてみます。 GETとPOSTの2本のテストに通過しました。 8.テストコードを追加してみる テストコードが少なすぎるので、Codexに愚痴をこぼします。 愚痴をこぼしたあとのページの確認がテストコードに追加されました。 submitのPOSTも含めてテストに通過しました。めでたしめでたし。 さいごに さて、今回はCodexの検証を行いましたが、コンテキストの渡し方以外は特に不便な点はありませんでした。 反省点としては、スタート地点でデザインについても言及するべきだったな・・・、と。 今回の検証でかかったコストは$2～$3くらいでした。 無駄なキャッチボールが多かったので、初期のプロンプトを最適化すればもっと安く済むと思います。 これからも AWS やAI関連の検証記事をたくさん書いていきます。 ↓ のスターを押していただけると嬉しいです。励みになります。 最後まで読んでいただき、ありがとうございました。 エンタープライズ 第一本部では一緒に働いてくださる仲間を募集中です。以下のリンクからお願いします。 私たちは一緒に働いてくれる仲間を募集しています！ 中途採用-エンタープライズ第一本部 新卒採用-エンタープライズ第一本部 執筆： 英 良治 (@hanabusa.ryoji) 、レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

初めまして。 エンタープライズ 第一本部、2年目の佐藤悠です。 最近話題の MCP サーバーを構築して、外部情報との連携をするという挑戦をします。 既出の内容かつ不正確な部分もあるかもしれませんが、私の個人的な検証記録として残しておきたいという目的でこの記事を作成します。 想定読者はジュニアレベルのエンジニアが MCP サーバーとは何か？どのように構築するか？を実例と共に知りたいという際に読むのがちょうど良いと思っています。 目次 MCPとは？ アーキテクチャ概要 テスト実行 追加の検証 まとめ 参考文献 MCP とは？ 提供元のAnthropicにおける説明[ 1 ]は以下の通りです。 The Model Context Protocol is an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools. 私の理解ではAI Agentが外部情報を取得する際の接続部の話だと思っています。 つまりは、 MCP サーバーを用いることでAI Agentと外部データリソース間での安全なコネクタの規格整備をしたということです。 統一規格が提供されているのでAI Agentに手軽に機能を載せたり、精度を向上させたりできるようになり、 MCP を中心にエコシステムが盛り上がりを見せているという現状の分析をしています。 2025年3月27日にはChatGPTのAgent SDK にも MCP をサポートするといったような旨の発表がありました。 このように異なるAI Agentで様々なデータソースを利用できるようになると、自由度や拡張性が高まりAI Agentの発展につながると感じますし、この潮流に乗りたいとも感じさせます。 以上が MCP の概観で、本記事を作成するモチベーションです。 アーキテクチャ 概要 本記事では、はじめに公式が提供しているQuickStart[ 2 ]と全く同じ構成でサーバーを作成してみました。 簡単な構成図は以下のとおりです。 ClaudeDesktopのインストールとサインインをあらかじめしておきます。 このアプリから MCP サーバーにアクセスし、天気の情報を取得するような構成です。 具体的には以下のツールを MCP サーバーに配置します。 get-alerts 指定された地域で現在出ている警報を取得する get-forecast 指定された地点の天気予報を取得する 私の環境は Windows なので、参考資料のその手順に従い実行したコマンドを載せています。 以下のコマンドを PowerShell で実行します。 uvをインストールし、 Python プロジェクトを用意します。 powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex" 次に作業 ディレクト リを作成し、移動。 仮想環境を作成して依存関係をインストール。 最後に Python のファイルを作成するコマンドを実行します。 # Create a new directory for our project uv init weather cd weather # Create virtual environment and activate it uv venv .venv\Scripts\activate # Install dependencies uv add mcp[cli] httpx # Create our server file new-item weather.py 以降の作業は、ここで作成したweather.pyを編集します。 ファイルの先頭に以下のコードを追加。 from typing import Any import httpx from mcp.server.fastmcp import FastMCP # Initialize FastMCP server mcp = FastMCP( "weather" ) # Constants NWS_API_BASE = "https://api.weather.gov" USER_AGENT = "weather-app/1.0" The FastMCP class uses Python type hints and docstrings to automatically generate tool definitions, making it easy to create and maintain MCP tools. ここの注釈にPyhtonの型ヒントとドキュメントで、このツールを定義しますとあります。 この部分の理解は実装後にできました。最後に解説します。 次に外部情報を取得する部分を実装しています。 #これがリクエスト処理 async def make_nws_request (url: str ) -> dict [ str , Any] | None : """Make a request to the NWS API with proper error handling.""" headers = { "User-Agent" : USER_AGENT, "Accept" : "application/geo+json" } async with httpx.AsyncClient() as client: try : response = await client.get(url, headers=headers, timeout= 30.0 ) response.raise_for_status() return response.json() except Exception : return None #これがフォーマッタ def format_alert (feature: dict ) -> str : """Format an alert feature into a readable string.""" props = feature[ "properties" ] return f """ Event: {props.get('event', 'Unknown')} Area: {props.get('areaDesc', 'Unknown')} Severity: {props.get('severity', 'Unknown')} Description: {props.get('description', 'No description available')} Instructions: {props.get('instruction', 'No specific instructions provided')} """ これは以下のツール内の処理で外部に情報を取得しにいく際と取得したデータ整形に使用しています。 get_alertsはUS state codeを期待しています。 これをURLのパスに加えることで、その地域の情報を API で取得できるという寸法です。 get_forecastも緯度・経度で同様の処理をリク エス トしていますね。 @ mcp.tool () async def get_alerts (state: str ) -> str : """Get weather alerts for a US state. Args: state: Two-letter US state code (e.g. CA, NY) """ url = f "{NWS_API_BASE}/alerts/active/area/{state}" data = await make_nws_request(url) if not data or "features" not in data: return "Unable to fetch alerts or no alerts found." if not data[ "features" ]: return "No active alerts for this state." alerts = [format_alert(feature) for feature in data[ "features" ]] return " \n --- \n " .join(alerts) @ mcp.tool () async def get_forecast (latitude: float , longitude: float ) -> str : """Get weather forecast for a location. Args: latitude: Latitude of the location longitude: Longitude of the location """ # First get the forecast grid endpoint points_url = f "{NWS_API_BASE}/points/{latitude},{longitude}" points_data = await make_nws_request(points_url) if not points_data: return "Unable to fetch forecast data for this location." # Get the forecast URL from the points response forecast_url = points_data[ "properties" ][ "forecast" ] forecast_data = await make_nws_request(forecast_url) if not forecast_data: return "Unable to fetch detailed forecast." # Format the periods into a readable forecast periods = forecast_data[ "properties" ][ "periods" ] forecasts = [] for period in periods[: 5 ]: # Only show next 5 periods forecast = f """ {period['name']}: Temperature: {period['temperature']}°{period['temperatureUnit']} Wind: {period['windSpeed']} {period['windDirection']} Forecast: {period['detailedForecast']} """ forecasts.append(forecast) return " \n --- \n " .join(forecasts) 最後にサーバーの初期化と実行を記述します。 この部分の意味は直接 スクリプト が実行された際に、標準入出力を通信手段に使うという意味です。 if __name__ == "__main__" : # Initialize and run the server mcp.run(transport= 'stdio' ) これで MCP サーバーの準備は終わりました。 次にClaudeがこのサーバーにアクセスできるようにします。 code $env:AppData\Claude\claude_desktop_config.json 以上のコードを PowerShell で実行します。これは単純にClaude Desktopの設定ファイルを書くために VScode を開くだけのものです。 開いたら以下の設定を記述。 { "mcpServers" : { "weather" : { "command" : "uv" , "args" : [ "--directory" , //ここは実際のweather.pyまでの絶対パスを記述する "/ABSOLUTE/PATH/TO/PARENT/FOLDER/weather" , "run" , "weather.py" ] } } } さっきまで編集していたweather.pyを実行するようにClaude側に指示しています。 これで標準入出力を待つサーバーが立ち、回答のための情報をどのツールで取得するかを選ぶ準備がClaudeでもできました。 それではテストです！ テスト実行 以下の画像の赤丸で囲った部分のハンマーアイコンが MCP サーバーに配置されたツールの数を示しています。 手順に沿っていれば2個のはずです。私は追加したので3の表示です。 私は実装直後はここで変更が反映されていませんでした。 以下のスクショのように、一度左上のメニューからファイル→終了（または表示→再読み込み）で戻ってくると反映されていました。 またメニューから開発者の機能を有効にすると MCP サーバーのログを見ることができるようになります。 他の原因で動作しなかった場合は、このログを参考に修正を加えると良いと思います。 反映されたら、ハンマーアイコンをクリックすると使用できるツールが表示されます。 では、ようやくですが参考資料に従って以下のプロンプトでテストを実行します。 What’s the weather in Sacramento? What are the active weather alerts in Texas? まずは一つ目。日本語でも指示が可能かも含めて検証しました。 What’s the weather in Sacramento? ツールを使用していいかの許可を聞くポップアップが出ます。 おお！無事 サクラメント の天気を取得できました。 次に二つ目。ちゃんと英語でも検証します。 What are the active weather alerts in Texas? 同様にツール実行のポップアップが出て、回答が生成されました。 何気なく使用していますが、ツールの引数に緯度・経度/US state codeを求めているのに回答生成できるの凄いですね！LLMが情報補完をしているのでしょう。 追加の検証 さらにツールを作ってみる実験をしました。 コードは以下のとおりです。 @ mcp.tool () def add (a: int ,b: int ) -> int : """例の処理といえばこれです. 引数： 数字：文章中の二つの数字 """ return a + b 今までの書き方を参考に、処理を追加しました！ 「例の処理」のように背景情報が必要なものはLLMは通常回答できません。 このツールの追加で足し算が実行出来たら、追加の検証は成功です。 出来ました！足し算はLLMでも回答できますが、「例の処理」の理解はできないですからね！ ちゃんとツール実行許可のポップアップも出現しました。 ここの注釈にPyhtonの型ヒントとドキュメントで、このツールを定義しますとあります。 この部分の理解は実装後にできました。最後に解説します。 最後に追加実装部分を例に上記の内容を解説します。 関数宣言の後に以下のテキストを追加していますね。 """例の処理といえばこれです. 引数： 数字：文章中の二つの数字 """ ここでしか、「例の処理」は記述していません。 つまり、関数の説明をテキストですれば、ツールを選択可能な状態にできるということですね。 型ヒントの部分も def add(a:int,b:int) -> int: のように記述することで、図中のプロンプトの後半、意味不明な数値の並び 例の処理を頼む 10 20 を解釈できていそうです。 検証は以上です。 まとめ MCP がなぜ盛り上がっているのかを実装してみて理解しました。 今のうちに詳しくなっておきたいですね！ 参考文献 [1] https://www.anthropic.com/news/model-context-protocol [2] https://modelcontextprotocol.io/quickstart/server#installing-prerequisites-macos 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @sato.yu 、レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

こんにちは。クロス イノベーション 本部 クラウド イノベーション センターの柴田です。 re:Invent 2024 で Amazon EKS Auto Mode の一般提供が発表されました。この記事では Auto Mode を利用する際に気をつけるべきことをご紹介します。 ℹ️ この記事の内容は 2025 年 2 月 22 日時点のものです。最新の情報は Amazon EKS の公式ドキュメント をご参照ください。 Amazon EKS Auto Mode とは Amazon EBS CSI driver OSS 版との主な違い OSS 版と併用できる OSS 版からリソースを移行できない Auto Mode のノード以外では利用できない Amazon VPC CNI plugin OSS 版との主な違い AWS Load Balancer Controller OSS 版との主な違い 設定項目が異なる OSS 版と併用できる OSS 版からリソースを移行できない .spec.loadBalancerClass のデフォルト値が eks.amazonaws.com/nlb になる 補足：Service, Ingress がどの controller によって処理されるか Service Ingress Karpenter OSS 版との主な違い 設定項目が異なる ノードの AMI は AWS によって管理される ノードは起動から最長 21 日経過すると終了する Pod からノードのインスタンスメタデータやインスタンスプロファイルを利用できない その他 他のコンピュートリソースと併用できる 組込みの NodeClass, NodePool は編集できない コスト 終わりに 参考資料 Amazon EKS Auto Mode とは Amazon EKS Auto Mode では以下のアドオンに相当する機能がマネージドサービスとして提供されます。 Amazon EBS CSI driver Amazon VPC CNI plugin AWS Load Balancer Controller CoreDNS Karpenter kube-proxy EKS Pod Identity Agent これにより クラスタ 管理者はこれらのアドオンの保守・運用から開放されます。 ℹ️ この記事では各アドオンの解説はしません。各アドオンの詳細はそれぞれの公式ドキュメントをご参照ください。 Amazon EBS CSI driver OSS 版との主な違い Auto Mode は Amazon EBS CSI driver と以下の違いがあります。 1 The block storage capability of EKS Auto Mode is different from the EBS CSI Driver. Static Provisioning If you want to use externally-created EBS volumes with EKS Auto Mode, you need to manually add an AWS tag with the key eks:eks-cluster-name and the value of the cluster name. Node Startup Taint You cannot use the node startup taint feature to prevent pod scheduling before storage capability readiness Custom Tags on Dynamically Provisioned Volumes You cannot use the extra-tag CLI flag to configure custom tags on dynamically provisioned EBS volumes You can use StorageClass tagging to add custom tags. EKS Auto Mode will add tags to the associated AWS resources. You will need to update the Cluster IAM Role for custom tags. For more information, see Custom AWS tags for EKS Auto resources. EBS Detailed Performance Metrics You cannot access Prometheus metrics for EBS detailed performance OSS 版と併用できる Auto Mode と Amazon EBS CSI driver は併用できます。 OSS 版からリソースを移行できない 既存の PersistentVolume の管理を Amazon EBS CSI driver から Auto Mode へ移行できません。 Auto Mode のノード以外では利用できない Auto Mode が管理する PersistentVolume を利用するためにはノードで Auto Mode の CSI driver の node plugin が動いている必要があります。そのため該当する PersistentVolume を利用する Pod は Auto Mode のノードで実行する必要があります。 同様に Amazon EBS CSI driver が管理する PersistentVolume を利用するためにはノードで Amazon EBS CSI driver の node plugin が動いている必要があります。 Amazon EBS CSI driver の node plugin の DaemonSet は Auto Mode のノードでは実行されません。そのため該当の PersistentVolume を利用する Pod は Auto Mode 以外のノードで実行する必要があります。 Amazon VPC CNI plugin OSS 版との主な違い Auto Mode は Amazon VPC CNI plugin と以下の違いがあります。 2 EKS Auto Mode does not support: Security Groups per Pod (SGPP). Custom Networking. The IP Addresses of Pods and Nodes must be from the same CIDR Block. Warm IP, warm prefix, and warm ENI configurations. Minimum IP targets configuration. Enabling or disabling prefix delegation. Other configurations supported by the open-source AWS CNI. Network Policy configurations such as conntrack timer customization (default is 300s). Exporting network event logs to CloudWatch. AWS Load Balancer Controller OSS 版との主な違い 設定項目が異なる 以下のリソースは AWS Load Balancer Controller と設定項目（フィールドや annotation）が異なります。 Service Ingress IngressClassParam TargetGroupBinding 詳細は以下のドキュメントをご参照ください。 Create an IngressClass to configure an Application Load Balancer - Amazon EKS Use Service Annotations to configure Network Load Balancers - Amazon EKS OSS 版と併用できる Auto Mode と AWS Load Balancer Controller は併用できます。 OSS 版からリソースを移行できない 既存の Service, Ingress の管理を AWS Load Balancer Controller から Auto Mode へ移行できません。 .spec.loadBalancerClass のデフォルト値が eks.amazonaws.com/nlb になる Service の .spec.loadBalancerClass が未指定の場合、 Auto Mode は mutating webhook によってこの値を eks.amazonaws.com/nlb に設定します。これには以下の影響があります。 AWS Load Balancer Controller にも 類似の mutating webhook があります。両者を有効にしている場合、正常に機能するのは片方のみです。 .spec.loadBalancerClass を未指定のままにできないため、新規に CLB を作成できません。 補足：Service, Ingress がどの controller によって処理されるか Service .spec.loadBalancerClass の値が eks.amazonaws.com/nlb の場合、 Auto Mode によって NLB が作られます。 以下のいずれかの場合、 AWS Load Balancer Controller によって NLB が作られます。 .spec.loadBalancerClass の値が service.k8s.aws/nlb の場合。 service.beta.kubernetes.io/aws-load-balancer-type annotation の値が nlb-ip または external の場合。 .spec.loadBalancerClass が未指定の場合、レガシー クラウド プロバイダーによって CLB が作られます。 3 ※前提として .spec.type の値が LoadBalancer であるとします。 Ingress .spec.ingressClassName に指定した IngressClass の .spec.controller の値が eks.amazonaws.com/alb の場合、Auto Mode によって ALB が作られます。 .spec.ingressClassName に指定した IngressClass の .spec.controller の値が ingress.k8s.aws/alb の場合、 AWS Load Balancer Controller によって ALB が作られます。 Karpenter OSS 版との主な違い 設定項目が異なる 以下のリソースは AWS Load Balancer Controller と設定可能な項目が異なります。 NodeClass NodePool 詳細は以下のドキュメントをご参照ください。 Create a Node Class for Amazon EKS - Amazon EKS Create a Node Pool for EKS Auto Mode - Amazon EKS 具体的な設定項目は kubectl explain コマンドでも確認できます。 ノードの AMI は AWS によって管理される Auto Mode では NodeClass の .spec.amiSelectorTerms （ノードの AMI に関するフィールド）を設定できません。Auto Mode のノードの AMI は AWS によって管理されます。 Auto Mode のノードの AMI には以下の特徴があります。 Bottlerocket OS を採用。 SSH や Session Manager によるノードへのログインは不可。 ただし kubectl debug node コマンドの実行は可能。 AWS が新しい AMI をリリースすると Karpenter がそれを検出して、 PodDisruptionBudget や NodeDirsuptionBudget を考慮しつつ、自動的に各ノードを新しいものに置換します。 トラブルシューティング の際は node monitoring agent を使ってノードのログを収集できます。詳しい方法は Retrieve node logs for a managed node using kubectl and S3 をご参照ください。 ノードは起動から最長 21 日経過すると終了する Auto Mode では NodePool の spec.template.spec.expireAfter spec.template.spec.terminationGracePeriod の合計は 504h 以下でなければなりません。つまり各ノードは起動から最長 21 日経過すると自動的に終了します。 Pod からノードの インスタンス メタデータ や インスタンス プロファイルを利用できない Auto Mode では NodeClass の spec.metadataOptions （ノードの MetadataOptions に関するフィールド）を設定できません。 Auto Mode のノードの MetadataOptions は以下のようになります。 " MetadataOptions ": { " State ": " applied ", " HttpTokens ": " required ", " HttpPutResponseHopLimit ": 1 , " HttpEndpoint ": " enabled ", " HttpProtocolIpv6 ": " disabled ", " InstanceMetadataTags ": " disabled " } HttpPutResponseHopLimit が 1 なので Pod からノードの インスタンス メタデータ や インスタンス プロファイルを利用できません。Pod に IAM role を割り当てる必要がある場合は代わりに以下のいずれかを利用する必要があります。 EKS Pod Identity IAM roles for service accounts その他 他にも Auto Mode は Karpenter と以下の違いがあります。 4 EKS limits the maximum number of pods on a node to 110. This limit is applied after the existing max pods calculation. For more information, see Choose an optimal Amazon EC2 node instance type. EKS Auto Mode automatically formats and configures NVMe local storage on supported instance types. For nodes with multiple NVMe drives, EKS sets up a RAID 0 array. This automation eliminates the need for manual formatting and RAID configuration of local NVMe storage in EKS clusters. Amazon EKS Auto Mode does not support AWS Fault Injection Service. For more information, see Managing Fault Injection Service experiments in the AWS Resilience Hub User Guide. You do not need to install the Neuron Device Plugin on EKS Auto Mode nodes. If you have other types of nodes in your cluster, you need to configure the Neuron Device plugin to not run on auto mode nodes. For more information, see Control if a workload is deployed on EKS Auto Mode nodes. 他のコンピュートリソースと併用できる Auto Mode は他のコンピュートリソース（ Managed Node Group や Fargate など）と併用できます。 組込みの NodeClass, NodePool は編集できない Auto Mode には以下の組込みの NodeClass, NodePool があります。 NodeClass default NodePool system general-purpose これらの設定は変更できません。異なる設定の NodeClass, NodePool を利用したい場合は独自の NodeClass, NodePool を作成する必要があります。 コスト Auto Mode のノードに対して追加料金が発生します。金額は EC2 インスタンス の料金の約 12% 程度のようです。詳細は以下のドキュメントをご参照ください。 Amazon EKS Pricing | Managed Kubernetes Service | Amazon Web Services 終わりに この記事では Amazon EKS Auto Mode を利用する際に気をつけるべきことをご紹介しました。 Auto Mode を有効にすることで クラスタ 管理者はいくつかのアドオンの保守・運用から開放されます。積極的に利用を検討したいですね。 最後までお読みいただき、ありがとうございました。 参考資料 Automate cluster infrastructure with EKS Auto Mode - Amazon EKS EKS Auto Mode - Speaker Deck 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @shibata.takao 、レビュー： @nagamatsu.yuji （ Shodo で執筆されました ） Create a storage class - Amazon EKS ↩ Learn about VPC Networking and Load Balancing in EKS Auto Mode - Amazon EKS ↩ 実際には Auto Mode の mutating webhook の影響で .spec.loadBalancerClass を未指定のままにすることはできません。 ↩ Create a Node Class for Amazon EKS - Amazon EKS , Create a Node Pool for EKS Auto Mode - Amazon EKS ↩

こんにちは！　グループ経営ソリューション事業部の 米久 保です。 私がマネージャーを担当するグループにて、ワークショップ形式で組織目標づくりをした話を書きます。 背景 マッキンゼーの7S ワークの進め方 ステップ1. Shared Valueを書き出す ステップ2. 6つのSを書き出す ステップ3. Shared Valueをすり合わせる ステップ4. Shared Valueを作文する ステップ5. 組織目標を考える ステップ6. メンバーと共有する やってみた感想 まとめ 参考文献 背景 多くの日本企業で導入されている目標管理手法の MBO は、「マネジメントの父」と呼ばれるP.F. ドラッカー 氏が提唱した考え方で、「Management by Objectives and Self-control」の略です。組織として成果を上げるためには、共通の目標（Objectives）を組織全体で共有することと、メンバーの「自律的な貢献」が重要です[1]。 Self-control の部分が鍵で（ MBO という略語に含まれないが故にしばしば抜け落ちてしまうのですが）、これがなければ MBO は形骸化し、上から押し付けられた目標をこなすという受動的なものになるリスクがあります。 個々人の目標は、所属する組織の目標にリンクしている必要があります。上位にあたる組織目標が、メンバーにとって 納得し共感できる ものであって初めて個人目標は意味のあるものとなり、それを達成したいという強いモチベーションが生まれます。 そのような「 腹落ちする組織目標 」をつくるために、マネージャーの私とリーダー二名、計三名でワークショップを開催しました。 マッキンゼー の7S マッキンゼー の7S （McKinsey 7S）は、組織の競争力強化を目的とし、組織の効率性を分析する用途で使われるモデルです。『エクセレント・カンパニー』の著者であるトム・ピーターズ氏らが、 マッキンゼー で コンサルタント をしていた1979年に開発しました[2]。 今回は企業レベルでの分析ではなく、目標づくりを目的としてチームの現状把握に用いるため、次の表のように解釈をしました。 要素 説明 Strategy 戦略 組織の強みと弱み。何をやり、何をやらないか。 Structure 組織構造 チーム構造と役割分担、コミュニケーション。 System システム プロセス、ルール、ツールなどの仕組み。 Shared Value 共通の価値観 チームの方向性を定め、活動の原動力となるもの。ミッションやバリュー。 Skill スキル チームとしてのスキル（組織能力）、個々人のスキル（技術力、ソフトスキル）。 Staff 人材 人材育成と成長、採用計画。 Style 組織風土 文化の醸成。 7Sのうち、「Strategy」「Structure」「System」を「ハードなS」、「Shared Value 」「Skill」「Staff」「Style」を「ソフトなS」と呼びます。一般的にはハードなSが重要視されがちですが、ソフトなSに対しても同等に注意を注ぎバランスを取ることが重要だとピーターズ氏は説きます。 ワークの進め方 では実際にどのような流れでワークを進めたかをご紹介しましょう。 ステップ1. Shared Value を書き出す まず、Shared Value を考える上でのネタ出しとして、 組織からどんなことを期待されているだろうか？ 自分たちはどうありたいか？ を思い思いに付箋に書き出していき、共有を行いました。 生データを公開することはできないのですが、たとえば「ビジネスのことを考えられるエンジニア集団になりたい」というような意見が出ました。 ステップ2. 6つのSを書き出す ハードなS（Strategy、Structure、System）、ソフトなS（Skill、Staff、Style）の順で、各要素についてのワークを以下の手順で行いました。 As Isのレーンに、現状の課題（黄色の付箋）と、うまくいっており継続し強化したいこと（水色の付箋）を書き出す ディスカッションをしながら、あるべき姿や方向性、目標を検討してTo Beのレーンに書き出す（水色の付箋） たとえば、Strategy（組織の強みと弱み。何をやり、何をやらないか）については、「高品質でバグが少ない」一方で「全体感を把握している人は一部のベテランのみで属人化している」という現状課題認識に基づき、「人に依存せず高品質を実現する仕組みづくり」を目指す、といった具合です。 ステップ3. Shared Value をすり合わせる ステップ1で書き出した「組織からの期待」「自分たちの想い」、およびステップ2で6つのSそれぞれに対して書き出したTo Beの内容を眺めながら意見交換をしました。掘り下げを行ったり、新たな気づきがあれば付箋を足したりします。 次のステップで ステートメント を作文する前準備として、Shared Value に含めたいキーワード候補を書き出していきました。 ステップ4. Shared Value を作文する ステープ3で書き出したキーワードを使い、 ステートメント としてShared Value を作文する作業を行いました。 メンバーの心に刺さり、共感を得て、モチベーション向上につながるような文章 を目指してあれこれ考えました。 最終的に我々のグループのShared Value ステートメント は以下となりました。 卓越した技術力と 人間力 で開発組織を牽引し、プロダクトビジネスを持続的に成長させることで業績拡大に貢献する ステップ5. 組織目標を考える ステップ4までの作業は、「腹落ちする組織目標」をつくるための前準備でした。次に、半年や一年といったタイムボックスにおける具体的な達成目標を定めます。 OKR （Objectives and Ker Results）という目標設定 フレームワーク （参考文献[1]によるとOKRは MBO の実践手法の一つとされる）の利用も検討しましたが、今回は以下の理由で見送りました。 我々のグループのメンバーは現在担当する業務が多岐にわたっており、共通のObjectives／Key Resultsを定めるのが難しい Key Resultsを 定量 的に表現するものが難しいものも多い 主要な活動（例「開発基盤のエンハンス・保守」）と、活動におけるトピック（例「次期バージョンのリリース」）で括り、それぞれについて責任を担うリーダーが以下を記入します。そして、他のリーダーが質問やコメントをして内容をブラッシュアップしました。 WHY（背景、意義） その活動／トピックを行う意義は何か 周囲や上位の組織にとって、どのような効果があるか 我々のグループにとって、どのような効果があるか WHAT（ゴール、達成すべきこと） どのような状態になっていれば、目標が達成できたと言えるか 定量 的に表現可能であれば、その達成目標値 ポイントは、 WHY（背景、意義）の内容がShared Value ステートメント で表現される価値観に繋がっていること です。それによって目標に対する納得感やモチベーションが高まります。 ステップ6. メンバーと共有する メンバー全員を集めて、作成した組織目標（Shared Value ステートメント と、活動・トピック毎の達成目標）を共有しました。あわせて、各リーダーは配下のメンバーに期待する目標内容（どのような役割で、どのような働きをしてほしいか）を文章化して共有を行いました。 やってみた感想 比較的長く一緒にやっているメンバー同士だったので、持っている価値観は共通する部分が多いと感じていましたが、 ワークを通して 言語化 することで相互理解をより深めることができた と思います。逆に、「思ったより◯◯の性向が強いんだな」というような気づきもありました。 組織目標は納得感があるものに仕上がったと思います。実際、その後メンバーが設定した各自の個人目標はしっかりと組織目標にリンクしており、チームとして同じ方向を向いていると実感しました。 今回はリーダーのみでワークショップを行いましたが、大規模なグループではないので、メンバー全員でやってみてもよいかなと思いました。 目標は設定して終わりではありません。 達成に向けて、ふりかえりなどによって高頻度に目標と向き合う 必要があります[3]。そのあたりもチームで取り組んでいきたいと考えています。 まとめ 本記事では、「 マッキンゼー の7S」モデルを用いた、ワークショップ形式による組織目標づくりをご紹介しました。ツールそのものよりも、 共に目標を作っていくプロセスによってチームの向かうべき方向を揃えていく という行為に意味があると思います。目標設定に悩みを持つマネージャーやチームリーダーにとって少しでも参考になれば幸いです。 記事末に 参考文献としてリストアップした書籍はどれも大変良い本ですので、是非参考になさってください。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 参考文献 [1] 坪谷 邦生 著 『図解 目標管理入門 マネジメントの原理原則を使いこなしたい人のための「理論と実践」100のツボ』 ディスカヴァー・トゥエンティワン （2023） [2] トム・ピーターズ 著 久保美代子 訳 『新エクセレント・カンパニー AIに勝てる組織の条件』 早川書房 （2020） [3] 小田中 育生 著 『 アジャイル チームによる目標づくりガイドブック OKRを機能させ成果に繋げるためのアプローチ』 翔泳社 （2024） 執筆： @tyonekubo 、レビュー： @nakamura.toshihiro （ Shodo で執筆されました ）

はじめまして。 エンタープライズ 第二本部、1年目の藤城龍之介です。 本記事では、ITほぼ未経験の状態から 応用情報技術者試験 において入社半年で上位約0.1％ に食い込んだ体験談と 10の戦略 を紹介します。 私が実際に行った学習方法や反省点も含めて、応用情報の戦い方を記しますのでぜひ参考にしていただければと思います。 なお、本記事では 応用情報技術者試験 を取り上げていますが、 その他の資格試験の対策に活用できるところもある かと思いますので、応用情報以外を受験する方もご一読いただければ幸いです。 目次 当時の私のスペックと状況 応用情報技術者試験の概要 勉強方法 スケージュールと勉強時間 使用した教材 インプット アウトプット（午前試験） アウトプット（午後試験） 試験直前 2日前 前日 試験本番 試験前 午前試験 昼休憩 午後試験 所感 結果 まとめ 10の戦略まとめ 最後に 当時の私のスペックと状況 ITほぼ未経験（電気系の理系大卒） 社会人1年目 IT系資格 保有 なし 理系科目は割と得意 暗記はかなり苦手 私が応用情報を受けようと思ったのは、ただ資格を取りたいというわけではなく、自社の研修とは別に自身でもIT系の知識をつけていきたいと思ったからです。 そこで、ITに関する体系的かつ使える知識を得られそうな応用情報を受験することにしました。（基本情報か応用情報が取得必須資格だったのもあるが...） 資格は取ることを目標にするのもいいですが、知識が体系的にまとめられており、効率よく知識を習得するのに最適だと考えています。 また、自身の知識を増やし、理解を深めることを目的に取り組むと気持ちも入りやすくなると思います。 応用情報技術者試験 の概要 応用情報技術者試験 は午前試験と午後試験があり、 どちらも60点以上 で合格です。 なお、午前試験で60点以上取らないと、午後試験は採点されないそうです。 午前試験 試験時間 9:30 ~ 12:00（150分） 出題形式 多肢選択式（四肢択一） 出題数 80問 午後試験 試験時間 13:00 ~ 15:30（150分） 出題形式 記述式 出題数 11問（解答は5問：1問必答、4問選択） 試験科目 1. セキュリティ（必答） 2. 経営戦略系 3. アルゴリズム 4. システム アーキテクチャ 5. ネットワーク 6. データベース 7. 組み込みシステム 8. システム開発 9. プロジェクトマネジメント 10. システムマネジメント 11. システム監査 勉強方法 それではここから勉強方法について紹介します。 スケジュールと勉強時間 入社と同時（4月）に勉強を開始しましたが、すぐにペースが落ちました。 結局7月末まではダラダラと勉強を続けていたため、この期間は平均するとおそらく1日あたり1時間くらい勉強していました。 8月になってさすがにマズいと思い、平日3時間、休日5時間くらいの勉強に切り替えました。 休日少なくない？と思った方もいると思いますが、趣味などに時間を使ったりして適度なリフレッシュをすることで勉強時間内にしっかりと集中することができました。 戦略①：適度なリフレッシュで勉強時間の効率を上げる → 特に休日は1:1くらいの割合でリフレッシュする というわけで、結局学習時間としては 約400時間 ほど取りました。 しかし、今思えば4～7月の勉強ではほとんど身に付いていない気がするので、実際には 約300時間 くらいだと思います。 もっと後から勉強開始して集中して取り組めていたら良かったと考えています。 戦略②：勉強開始は集中力を保てる期間を見据えてから → 応用情報は3, 4か月前がオススメ 使用した教材 使用した教材は3つで、以下で紹介する3つのフェーズごとに使い分けておりました。 書籍 令和06年【春期】【秋期】 応用情報技術者 合格教本 2024　応用情報技術者　午後問題の重点対策 Webサイト 応用情報技術者過去問道場 インプット（~ 9月中旬） インプットで使ったのは 合格教本 で、暗記が苦手な私は以下のようにインプットしました。 ちなみに、私はテク ノロ ジ系の知識が欲しかっただけなので、この教材のマネジメントとストラテジは飛ばしました。 → 後のアウトプットで何とかなりました ・1周目：理解できないところがなくなるようにノートに書きながら読む ⇒ 丸暗記ではなく、原理や考え方などを他の要素と結び付けながら理解することで暗記量をできるだけ減らしました。 ・2周目：自身が書いたノートを読み返して復習 → 理解できていないところは再度書きながらチェックする ⇒ 1周だけでは完璧に理解できないので、分かりづらいと感じたところはインターネットも併用しながらさらに理解を深めました。 ・3周目：さらにノートで復習 → 暗記するしかないところを覚える ⇒ とにかく丸暗記するという行為が嫌いなので、2周してできるだけ丸暗記の量を減らし、最後の最後で暗記するしかないところを覚えました。 このように、体系的に繋げて理解することを念頭に学習を進めることで、丸暗記の量を減らすことができる上、内容も十分に理解することもできました。 当初の目的であった、体系的かつ使えるITの知識を得ることができたと思います。 暗記が得意な方も、応用情報の範囲は莫大で丸暗記するにはかなりの根気がいると思いますので、ぜひ「繋げて理解する」ことを念頭に勉強していただければと思います。 戦略③：丸暗記をやめて体系的に「繋げて理解する」ことに専念する → 繋げて理解することで、使える知識へと昇華できる、かつ最終的に時短にもなる アウトプット（午前試験 / 9月下旬） インプットで9月中旬くらいまで使い、ここでやっとアウトプットに入りました。 まずは午前試験対策です。 9月末を使い、 過去問道場 で午前試験の過去問を3年分（6回分）、解きました。 ここで意識したことは以下の3点です。 1. 試験方式を確認し、慣れること 2. 知識の抜け漏れを補完し、インプットで得た知識を確認すること 3. マネジメントとストラテジ（インプットをしなかった科目）について知ること まず意識することは、試験で問題がどのような形式で出て、どのような時間配分で解けばいいのかを確認することです。 これは6回分もやれば十分につかめると思います。 次に、知識の抜け漏れを補完することです。（ これが重要！ ） インプットで入れたものは100%定着するわけではないので、ここでさらに思い出すことによって知識を補完・確認していきます。 また、試験では多少 合格教本 に書いていないことも出題されるので、そこについてはインプットフェーズのように新たに知識を入れていきます。 なお、マネジメントとストラテジについてはここで問題を解くことで十分に解けるようになりました。 ＊ 欲しい知識には個人差があるので、おすすめしているわけではありません。 戦略④：アウトプットはあくまで試験の形式の確認と知識の補完・確認 → インプットで得た知識を確認すると共に抜け漏れをなくす 過去問はたくさん解いた方が良いとは思いますが、IT業界の知識は日々アップデートされていくのでそこまで古い過去問に手を出す必要はないと思います。 再度になりますが、実際にやってみて6回分も解けば十分だと思いました。 戦略⑤：過去問を解くのは適度に終わらせて良い → 6回分で十分 アウトプット（午後試験 / 10月上旬） 10月に入り、午後試験の対策を始めました。 午後試験は1回分が長く、自分で問題を厳選するのが面倒だったため、 午後問題の重点対策 を使って、どのような問題が出るのか掴むことにしました。 基本的には、解く問題をある程度先に絞ってからその分野だけ過去問を解いて慣れていくことがオススメです。 午後試験は4問が選択問題で、6問は解かない問題になるので、時間が十分にある方以外は選択する問題を絞って勉強するのが効果的だと思います。 私は以下のように午後問題を絞りました。 確実に解く問題は2, 3問決めておき、問題文を見て決める問題を1, 2問に絞っておくと学習も本番も余裕ができます。 あくまで私の特性（長文を読むことが苦手）とこれまでの学習方法に対する選定方法なので、自身の特性と学習状況に応じて選定してみてください。 〇：確実に解く問題 △：本番の問題文読んでから決める問題 ✕：絶対に解かない問題 △ → ✕：問題集を解いてみた結果、絶対解かないように変更した問題 科目 選択 説明・選定理由 1. セキュリティ 必須 午前の知識がある前提で、問題を読めば解ける 2. 戦略系 ✕ 文章が長く、知識も浅い 3. アルゴリズム 〇 変数の説明をしっかり読み、具体例や図を用いて明確化すれば解ける 4. システム アーキテクチャ △ → ✕ 計算問題が多く、ミスもしやすい傾向があった 5. ネットワーク △ 記述が難しいことがあるが、ある程度の得点源になる 6. データベース △ いかついER図などが出てきてタイパが悪い回がある 7. 組み込みシステム 〇 知っているモノが出ることが多く、事例が理解しやすい 8. システム開発 〇 事例を理解することに専念すれば、あとは自社の研修内容で解ける 9. プロジェクトマネジメント ✕ 文章が長く、知識も浅い 10. サービスマネジメント ✕ 文章が長く、知識も浅い 11. システム監査 △ → ✕ 文章が長い このように、事例の文章も長く、インプットをしなかったマネジメント、ストラテジ系以外の問題（6問）を解いて検証し、自分にあったものをスタメンとしました。 できるだけ絞ることで、勉強の効率が大幅に上がるのに加え、本番で問題を読んで迷って時間を食うこともないので、学習の段階から絞って勉強するのはかなりオススメです。 戦略⑥：午後問題は思い切って絞る → 確実に解く問題を2, 3問に絞り、重点的に学習する 試験直前 2日前 試験2日前は、アウトプットに使っていたノートを見ながら復習をしました。 どのような問題でミスしたかを再確認することで、もう一度記憶を整理し、定着させました。 前日 前日はインプットに使っていたノートで復習をしました。 学んだことを確認し、知識の結びつきを再度整理することで、本番に向けて準備を整えることができたと思います。 それ以外の時間は趣味に充て、頭を休めました。 戦略⑦：試験直前は復習するだけ → 直前に詰め込もうとしても焦りでインプットできないため、やったことを復習し、あとは自由に過ごす 試験当日 試験前 会場は行ったことがない駅の近くの専門学校でした。 朝早かったこともあり、集合時間の 1 時間前くらいに会場の最寄り駅まで行き、集合時間ギリギリまで近くの公園で朝ご飯を食べながらノートで最終確認をしていました。（教室は空気が重く不自由だったのでこの選択は正解だった…） ちなみに、持って行った教材は自分がインプットとアウトプットで使ったノート4冊です。 戦略⑧：試験日の朝は周りの空気に呑まれないように → 自分でその環境を作り出すことが大事 午前試験 午前試験では分からない問題はとにかく後回しにして、まず一通り解き終わることを目標にしました。 結局大幅に時間が余ったため、分からなかった問題も含めて 3 回くらい見直しをすることができました。 昼休憩の時間に 過去問道場 のサイトで解答速報が出るので、それに備えて問題に自分の解答を書き込んでおくことも大切です。 早く解き終わったら退出できるので、昼休憩を有効に使いたい人は退出するのもオススメです。 昼休憩 昼休憩時は、朝と同様の公園で昼ご飯を食べながら、解答速報を見て答え合わせをしました。 合格ラインに乗っていたので、心置きなく午後試験に臨むことができたと思います。 昼休憩は多少の復習もしましたが、公園で少し体を動かすことでかなりのリフレッシュになりました。 戦略⑨：昼休憩は頭を休める → 体を動かしたりして気分転換をする 午後試験 午後試験は立てた戦略通り、確実に解く問題である、以下の問題を先に解きました。 1. セキュリティ 3. アルゴリズム 7. 組み込みシステム 8. システム開発 しかし、この年は組み込みシステムがとても難しく感じ、ここだけは一旦問題用紙に解答を書き込んでネットワークとデータベースを解くことにしました。 問題文を読み始めると、想定よりもネットワークが簡単だったため、その後の解答にかなりの余裕ができ、ネットワークとデータベース、組み込みシステムを全て解いて比較することができました。 結果的には、想定よりも簡単だったネットワーク、少しでも点が取れる見込みのあった組み込みシステムを解答として提出しました。 所感 過去問をあまり多く解いていないこともあり、見たことのない問題が多かったですが、繋げて理解することにフォーカスして勉強した結果、当日も考えながら解答を導出できたと思います。 また、午後試験で多少の想定外のトラブルがありましたが、落ち着いて別の解答を進めることで最終的には時間に余裕ができたため、この方法を取ってよかったと思っています。 戦略⑩：試験時に分からない問題は後回し → 分かる問題から解き進めることで時間と心の余裕を確保する 結果 結果は… 無事合格できました！ 午前が85点、午後が90点です。 得点分布をみると、午前は上位約3%、午後は上位約0.1%でした。 IT ほぼ未経験からここまで得点を上げることができたのも、理解に専念したからだと思っています。 特に午後は過去問が出ることはないので、どれだけ理解しているかがものを言うと思います。 そのため、午前よりも午後の方が得点が高い結果となったのだろうと思っています。 まとめ 10の戦略まとめ ここまでで紹介した10の戦略をまとめておきます。 人によって合う合わないがあるかと思いますが、参考にしていただければ幸いです。 ● スケジューリング 戦略①：適度なリフレッシュで勉強時間の効率を上げる → 特に休日は1:1くらいの割合でリフレッシュする 戦略②：勉強開始は集中力を保てる期間を見据えてから → 応用情報は3, 4か月前がオススメ ● 学習 戦略③：丸暗記をやめて体系的に「繋げて理解する」ことに専念する → 繋げて理解することで、使える知識へと昇華できる、かつ最終的に時短にもなる 戦略④：アウトプットはあくまで試験の形式の確認と知識の補完・確認 → インプットで得た知識を確認すると共に抜け漏れをなくす 戦略⑤：過去問を解くのは適度に終わらせて良い → 6回分で十分 戦略⑥：午後問題は思い切って絞る → 確実に解く問題を2, 3問に絞り、重点的に学習する ● 試験直前 戦略⑦：試験直前は復習するだけ → 直前に詰め込もうとしても焦りでインプットできないため、やったことを復習し、あとは自由に過ごす ● 試験当日 戦略⑧：試験日の朝は周りの空気に呑まれないように → 自分でその環境を作り出すことが大事 戦略⑨：昼休憩は頭を休める → 体を動かしたりして気分転換をする 戦略⑩：試験時に分からない問題は後回し → 分かる問題から解き進めることで時間と心の余裕を確保する 最後に ここまで読んでいただきありがとうございます。 応用情報はかなり出題範囲が広く、網羅するのは根気が必要ですが、「繋げて理解する」ことで効率的に学習を進めていきましょう。 あくまで私の学習方法と戦略ですが、今後応用情報を勉強する方の一助となれば幸いです！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @fujishiro.ryunosuke 、レビュー： @handa.kenta （ Shodo で執筆されました ） table { width: 100% !important; border-collapse: collapse; } td { border: 1px solid #000; padding: 8px; word-wrap: break-word; } td:first-child { background-color: #d3d3d3; font-weight: bold; } blockquote { border-left: 5px solid #388e3c !important; background: #e8f5e9; padding: 10px; }

こんにちは。 エンタープライズ 第一本部の新人、佐藤悠です はじめに 質問しまくる新人の私 タスクは思考の過程から文字に起こす新人の私 RAGとは Bedrock knoeledgebasesでRAGを作成してみた 参考資料 はじめに 質問しまくる新人の私 私は現在、先輩社員の手を煩わせながら日々の業務を行っています。 先輩は質問を歓迎していますが、将来自分が同じ立場になった際に同じ振る舞いができる気がしないので今から対策をしようと思いつきました。 仕事で分からないことは当然のようですが2つに分けることができると思っています。 調べれば分かること 聞かないと分からないこと 当たり前ですが新人は聞かないと分からないことで質問をします。（私は調べればわかるが聞いた方が早そうなことは聞きますけど...） 業務上ではこのような聞かないと分からないような属人的な知識を扱うことがあります。 現場では、ほとんどが文書化されデータが存在しアクセス可能なところにありますが、規模が大きく複雑化した結果、その文書のありかを知っている人が限られているというような状態にも陥りがちです。 タスクは思考の過程から文字に起こす新人の私 私はあまりワーキングメモリがなく、次々と考えることが増えたときや次の日に持ち越した際に何をすればいいのか分からなくなりやすいので、以下のようにmdファイルでまとめたものがタスクごとに存在しています（実案件のものなので文字は読めないようぼかしてます）。 ここで割とこまめに文書に書き起こす自分の特徴とRAGって相性いいなと感じました。 前置きが長くなりましたが、この記事では業務上で扱う個別具体的な情報を回答できるように、自分がまとめたmdファイルでRAGを作成できるのかを技術的に検証します。 RAGとは 大規模 言語モデル 自体に変更を加えることなく参照する情報を指定することでハルシネーションの回避や特有の知識に対する回答の精度を高めることができます。 今回は以下のような構成を AWS 上で準備することを考えます。 LangChainでRAGを実装することもできますが普段使用している AWS でフルマネジドで作成することができるBedrock Knowledge bases[1]が簡単なので今回はこれを使用します。 Bedrock Knowledge basesでRAGを作成してみた 埋め込むデータは検証なので以下のようなダミーデータにしました。 これをRAGを使用せずに生成AIに案件Bの担当者は誰ですかと聞いても答えることは不可能でしょう。 では、先ほどのmdファイルをデータソースとして使用するためにS3に配置します。 次にBedrock Knowledge basesでこれを埋め込みするソースに指定します。 マネジメントコンソールでBedrockと検索し左のメニューからKnowledgebaseを選択します。 Knowledgebaseを作成を押下すると遷移先の画面でデータソースを指定できます。 次へを押下した遷移先で実際にmdファイルを置いた バケット の URI を指定します。 後は特別な設定をしない場合はアクセス許可をした埋め込み用のモデルを指定して、ベクトルデータベースをクイック作成で完了です。 ストア先は OpenSearch を使用しました。 作成したデータソースを同期します。 では無事に検索するべき情報をコンテキストに渡す準備ができました。 以下の指示にどのような回答が返ってくるかテストします。 いかに....!? 生成AIの思考では出せない一般的ではない名前のデータを出力させることに成功しました。 これで検証を終わります。 社内情報を使用していいのかとかの線引きを含めて超えないといけない壁は複数ありそうですが、技術的にできるのは嬉しいです。 ここまで読んでいただきありがとうございました。 参考資料 [1]How Amazon Bedrock knowledge bases work https://docs.aws.amazon.com/bedrock/latest/userguide/kb-how-it-works.html 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @sato.yu 、レビュー： @nagamatsu.yuji （ Shodo で執筆されました ）

こんにちは、クロス イノベーション 本部エンジニアリングテク ノロ ジー センターの小澤英泰です。 本記事では GitHub Discussionsで ADR を管理する方法を紹介します。 はじめに ADRとは 筆者チームのGitHubとの関わり方 ADR導入の目的 ADRに備えたい性質 記載内容 運用 ADRの構成 全体構成 個別の説明 タイトル ステータス コンテキスト 決定 影響 コンプライアンス 参考情報 備考 ADRのステータス管理 ステータスの遷移図 個別のステータス Draft（ドラフト） Proposed（提案中） Review Rejected（却下） Accepted（承認済み） Deprecated（非推奨） Superseded（置き換え） 他のドキュメントとの違い ADRの管理にGitHub Discussionsを採用した理由 比較観点 比較検討 結果 Discussions リポジトリのdocsフォルダ Issues Wiki GitHub Discussionsでの運用で得たTips 無効なADRもOpenのままとする DiscussionとIssueに関連を持たせる アーキテクチャの決定をGitHub Copilotに読ませる さいごに ADRの例 ステータス コンテキスト 決定 結論 採用の選択肢とその理由 GitHub Packages(npm packages) 採用見送りの選択肢とその課題 GitHub Packages(Docker Images) Monorepo Micro Service 影響 コンプライアンス 参考情報 備考 はじめに ADR とは ADR とは Architecture Decision Record の略称で、定義は AWSのADRに関するドキュメント を拝借します。 An architectural decision record ( ADR ) is a document that describes a choice the team makes about a significant aspect of the software architecture they’re planning to build. Each ADR describes the architectural decision, its context, and its consequences. ADRs have states and therefore follow a lifecycle. ADR とは、チームが構築するソフトウェア アーキテクチャ の重要な選択を記述する文書です。 各 ADR には、 アーキテクチャ の決定、その背景、およびその結果を記述します。 ADR には状態とライフサイクルがあります。 Architecture Decision Recordをカタカナで アーキテクチャ ディシジョンレコード と表記する場面もありますが、手短に本ブログでは ADR で統一します。 定義だけでは想像が難しいと思いますので、ご参考までに 本記事の最下部にプロジェクトで管理するADR を記載しました。 筆者チームの GitHub との関わり方 本題に入る前に、筆者チームにおける GitHub の活用方法を紹介します。 私たちは普段5人前後の開発チームでプロダクト開発を行うことが多く、プロダクトオーナーもGit/ GitHub を積極的に活用します。構成管理以外にも下記のようにプロダクト開発で扱うツールを GitHub に集約し、連携することでメリットを最大限に引き出すことを目指しています。 GitHub Actions: CI/CD GitHub Codespaces: 開発環境 GitHub Discussions: 技術に関する議論や ADR 、議事録の管理 GitHub Issues: 課題管理 GitHub Packages: ソフトウェアパッケージの ホスティング GitHub Pages: Storybookや API 仕様書の ホスティング GitHub Projects: プロジェクト管理 ドキュメント管理においては、 GitHub を信頼できる唯一の情報源として位置づけ、他のツールとの分散を避けることで、情報の一元化と信頼性の向上を狙っています。 また、 アーキテクチャ の決定に影響のあるすべてのメンバーが GitHub にアクセスできることを前提とし、透明性を確保しながらプロダクト開発をしています。 ADR 導入の目的 それでは、本題に入っていきましょう。 ADR 導入の目的は 未来のプロジェクトメンバーが当時の アーキテクチャ 決定の トレードオフ まで理解できること です。 特定の課題により採用を見送った アーキテクチャ についても、経緯と判断理由を記録することで、将来のリ アーキテクチャ 時に同様の問題を見落とし、障害やリスクを引き起こすことの未然防止を目的としています。オーラルヒストリーで課題を引き継ぐのは困難を伴うでしょう。 ADR に備えたい性質 次に、上記目的を達成するための ADR に備えたい性質を 記載内容 と 運用 の観点で整理します。 記載内容 採用 アーキテクチャ と採用理由 採用を見送った アーキテクチャ と課題 関連する利用中の技術や業務、組織的な制約 ドキュメントの有効と無効を判別できるステータス 運用 簡潔なテンプレートがある 作成およびメンテナンスのコストが低い 継続的な運用フローがある すべてのプロジェクト関係者がアクセスできる 誰がいつ何を変更したかを追跡できる 他のドキュメントやコードと整合性が取れている 適切にレビューされ、承認されている ADR の構成 上記の目的や性質を踏まえ、 ADR の構成を下記としました。 全体構成 タイトル ステータス コンテキスト 決定 影響 コンプライアンス 参考情報 備考 個別の説明 タイトル アーキテクチャ 決定の簡単な説明 フォーマットは [ADR_番号] タイトル 例、 [ADR_002] 基盤コードの公開方法 ステータス ステータスは6種類あり Draft（ドラフト） Proposed（提案中） Accepted（承認済み） Rejected（却下） Deprecated（非推奨） Superseded（置き換え） ステータスの詳細は後述の ADR のステータス管理 を参照 コンテキスト 決定を下した状況 利用中の既存技術との兼ね合いや組織や体制、ビジネス面の時間的な制約を踏まえる 決定 決定と根拠 他の採用を見送った候補と課題 影響 決定による影響 コンプライアンス 決定が遵守されていることを確認する方法 参考情報 参照すべき一次情報 理解を促すブログ（任意） 備考 その他の備考（任意） ADR のステータス管理 ADR のステータス遷移と、レビューのプロセスを定義します。 Acceptedのステータスが唯一、 ADR が有効であることを示します。 ステータスの遷移図 個別のステータス Draft（ドラフト） 提案者が作成中の状態 他のメンバーへは周知前 Proposed（提案中） 周知済みでありレビュー可能な状態 Review ※ 判断でありステータスではありません。 レビュー完了の場合、承認または却下へ進む 指摘事項ありの場合、修正者へ差し戻す Rejected（却下） レビューを経て採用せず却下とした状態 ADR 作成者は却下の理由を ADR に追記する 決定が無効であることを示す Accepted（承認済み） レビューを経て承認した状態 決定が有効であることを示す Deprecated（非推奨） 承認済みの ADR を技術または業務、その他の理由により推奨しない状態 決定が無効であることを示す Superseded（置き換え） 既存の承認済みの ADR の内容を、更新または代替する新しい ADR を承認した状態 決定が無効であることを示す 承認済みの ADR を随時更新せず、新規 ADR を作成することに注意 他のドキュメントとの違い ADR と類似するドキュメントの 伝統的な アーキテクチャ 記述 や DesignDoc との違いを整理します。 伝統的な アーキテクチャ 記述（Traditional Software Architecture Description） とは、『 Design It! 』にて言及のある、権威的であり成果物に含まれる設計ドキュメントです。膨大で包括的な特徴があります。 DesignDoc とは、特定の機能の設計方針や技術選定をまとめ、開発チーム内での合意形成や意思決定に扱う設計ドキュメントです。 ADR と重複する部分もありますが機能や処理方式に焦点を当てています。DesignDocを作成する場合は、 アーキテクチャ 決定に関する部分を ADR に記載し参照とするのもよいでしょう。 伝統的な アーキテクチャ 記述 DesignDoc ADR 目的 システム全体の アーキテクチャ を記録 特定機能や設計変更の記録 特定 アーキテクチャ 上の決定を記録 スコープ システム全体 特定の機能や コンポーネント 特定の決定やその影響範囲に限定 記録内容 システム全体の構造、依存関係、非機能要件など包括的に記録 機能の設計詳細や技術的 トレードオフ 決定の背景、選択肢、結論、影響を記録 作成タイミング プロジェクトの初期段階から納品までの期間 機能開発前や開発中 機能変更が生じたタイミング 重要な アーキテクチャ 決定が行われたタイミング 利用期間 長期的（システムが稼働する限り） 長期的（機能がある限り） 長期的（決定が有効な間） 更新頻度 低 高 低（承認後の内容は更新せず新たに作成） 更新難易度 高 低 低 形式 権威的で公式 簡潔 簡潔 内容の粒度 詳細かつ包括的 実用的かつ軽量 実用的かつ軽量 主な読者 開発チーム、運用チーム、納品先 開発チーム 開発チーム ADR の管理に GitHub Discussionsを採用した理由 筆者チームのGitHubとの関わり方 のとおり、ツールは GitHub に集約する方針のため、ドキュメント管理も GitHub で運用する前提があります。 GitHub の中でもドキュメントを管理する方法は複数あり、下記4つの候補を検討しました。 Discussions リポジトリ のdocsフォルダ Issues Wiki 比較観点 ADR の GitHub での管理方法の4候補を下記5つの観点で比較します。 構成管理 誰がいつ何を変更したか追跡できるか テンプレートの利用 決まったフォーマットで新規作成できる、または複製できるか 検索性 タイトルや内容を特定ワードで検索できるか フィルターの容易性 他用途のドキュメントと分離できるか ADR の一覧化をできるか ADR にレビューを残せるか レビューコメントをどこに残すか 比較検討 結果 下表の比較結果より、 ADR 管理にはDiscussionsを採用しました。 Discussions リポジトリ のdocsフォルダ Issues Wiki 構成管理 ◎ ◎ ◎ ◎ テンプレートの利用 ◎ ◎ ◎ ◯ 検索性 ◎ ◎ ◎ ◯ フィルターの容易性 ◎ ◯ ◯ ◯ ADR にレビューを残せるか ◎ ◯ ◯ × ◎: 容易に可能 ○: 可能 ×: 不可能または現実的でない Discussions 構成管理（◎） 右上のeditedのプルダウンから追跡可能 ステータス管理の方法から通常のコードと比較して、変更数は少ないため十分と判断 テンプレートの利用（◎） Discussion Templateでテンプレート化可能 .github/DISCUSSION_TEMPLATE/{categoryName}.yaml のようにカテゴリ名の YAML を作成。Issue Templateと異なり YAML のファイル名に規則あり。詳細は公式ページを参照 ディスカッション カテゴリ フォームの作成 検索性（◎） テキスト検索が可能 フィルターの容易性（◎） サイドバーの ADR のカテゴリー選択によるフィルター（1クリック） ラベルでのフィルターも可能 ADR ラベルと ADR のステータスのラベル、関連技術のラベル付与により視認性向上 ADR にレビューを残せるか（◎） Discussion内でのコメントとしてレビュー テーマごとにスレッド化して、スレッド内でリプライ可能 ADR 本体とレビューのコメントが同一ページにあり、思考過程を辿ることができる リポジトリ のdocsフォルダ 構成管理（◎） 明らか テンプレートの利用（◎） テンプレートファイルを用意し、複製利用 検索性（◎） テキスト検索が可能 フィルターの容易性（◯） /docs/ adr 配下に集約することで他のドキュメントと分離 /docs/ adr 配下にフラットに配置するか、 ADR の種類に応じて ディレクト リを切るかは検討の余地ありのため評価は◯ ADR にレビューを残せるか（◯） PRにてレビュー。 ADR から該当のPRを探す手間ありのため評価は◯ GitHub 上からファイルをBlameビューで表示してPRを辿る Issues 構成管理（◎） 右上のEditsのプルダウンから追跡可能 テンプレートの利用（◎） Issue Templateでテンプレート化可能 .github/ISSUE_TEMPLATE/{templateName}.yml でテンプレート化 検索性（◎） テキスト検索が可能 フィルターの容易性（◯） Labelsのプルダウンから ADR ラベルでフィルター（2クリック） Discussionは1クリックのため評価は◯ ADR にレビューを残せるか（◯） スレッド化はできないがフラットにコメント可能なため評価は◯ Wiki 構成管理（◎） revisionsから追跡可能 テンプレートの利用（◯） テンプレートのページを作成し、複製利用 ファイルの複製と比較すると手間があるため評価は◯ 検索性（◯） Wiki 単体に検索機能はないが、 リポジトリ 全体で検索可能なため評価は◯ フィルターの容易性（◯） サイドバーで階層構造を表現できるが手間があるため評価は◯ ADR にレビューを残せるか（×） ADR に追記することでレビューとコメントが可能だが現実的でないため評価は× GitHub Discussionsでの運用で得たTips GitHub Discussionsを用いて、 ADR 管理をシンプルに運用することができます。運用する中で得たTipsを紹介します。 無効な ADR もOpenのままとする ADR のステータスがDeprecated、Rejected、Supersededに変化し、無効な ADR となってもDiscussionはOpenのままで運用します。これは GitHub Discussionsのデフォルトのフィルター条件がOpenなDiscussionのみ表示のためです。無効な ADR 含め一覧で見たいため、無効な ADR もCloseしません。 DiscussionとIssueに関連を持たせる Discssionに記述した ADR がIssueの課題に関連を持つ場合は辿れるように相互にリンクを貼ります。 Discussionsページの検索窓からはIssueは検索範囲外です。Issueやコードを含めて検索したい場合は、 リポジトリ 全体で検索しましょう。 アーキテクチャ の決定を GitHub Copilotに読ませる 2025年3月時点では、 GitHub Copilotは GitHub Discussionsのドキュメントを読み取ることはできないようです。 アーキテクチャ の決定を GitHub Copilotに読ませたい場合は、必要な箇所を リポジトリ のdocsやREADME、copilot-instructions.mdに記載しましょう。 さいごに ADR の目的から構成やステータスを定め、 GitHub Discussionsを用いて ADR を管理する方法を紹介しました。今後の運用で新たな気づきがあれば、改めて記事を投稿したいと思います。 プロジェクトによって ADR の最適な管理方法は異なりますが、1つの例として参考になれば幸いです。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト ADR の例 タイトル: [ ADR _002] 基盤コードの公開方法 ステータス Proposed コンテキスト 案件カスタマイズをする際に基盤のコードを利用し、容易に案件カスタマイズを実施できるようにしたい。 基盤のコードをどのようにパッケージングし、公開するかを検討する。 決定 結論 以下の候補を検討し、 GitHub Packages(npm packages)として公開することとする。 GitHub Packages npm packages Docker Images Monorepo Micro Service 評価の観点は以下。 独立性 基盤コードと案件コードが独立しているか 利用容易性 案件側から容易にパッケージを利用できるか パッケージのインターフェースは便利か カスタマイズ性 案件側で振る舞いを変更できるか 案件側で振る舞いを上書きできるか 拡張性 基盤コードはメンテナンスしやすいか 基盤コードは機能追加しやすいか 方法 独立性 利用容易性 カスタマイズ性 拡張性 GitHub Packages(npm packages) ◯ △ ◯ ◯ GitHub Packages(Docker Images) ◯ △ × △ Monorepo × ◯ ◯ × Micro Service ◯ × ◯ ◯ 採用の選択肢とその理由 GitHub Packages(npm packages) 独立性（◯） - 基盤コードと案件コードで リポジトリ を分割可能 パッケージはバージョニングできるため、基盤コードのバージョン間でも独立している 利用容易性（△） ユーザはnpm installで利用可能 実装にもよるがライブラリ形式のためある程度の利便性 コンポーネント の組み合わせ相当の実装は呼び出し側の責務となり、多少実装コストがある カスタマイズ性（◯） 引数やpropsによって振りまいを変更可能 利用しにくい コンポーネント は独自 コンポーネント で差し替えることが可能 メンテナンス・拡張性（◯） 新しい コンポーネント を追加したり、 コンポーネント のpropsを増やしたりし、機能追加が可能 採用見送りの選択肢とその課題 GitHub Packages(Docker Images) 独立性（◯） リポジトリ を分割できる バージョニングできる 利用容易性（△） Docker Image形式で利用可能 呼び出し側はDocker実行時のパラメータを変更するのみ パラメータが大量になる可能性あり カスタマイズ性（×） パラメータを変更することで振る舞いを変更可能 振る舞いの上書きはできない パラメータ以上の振る舞い変更は不可能 拡張性（△） 実行時パラメータを増やすことで拡張可能 カスタマイズの数だけ実行時パラメータが増えてしまう 引数が大量にあるDocker Imagesは基盤側にとっても案件側にとっても便利ではないと予想 Monorepo 独立性（×） ディレクト リ相当のため、独立性があるかと言われると微妙 案件担当者が基盤コードを直接参照したり、修正できたりする バージョニングできない 利用容易性（◯） npm workspaceなどを使ったライブラリの形式になる ライブラリ形式のため GitHub Packages(npm packages)と同程度か コードのコピペも可能 カスタマイズ性（◯） パラメータを変更することで振る舞いを変更可能 パラメータ以上の振る舞い変更は不可能 メンテナンス・拡張性（×） - バージョニングができないため、基盤コードの修正とリリースが簡単に実施できない Micro Service 独立性（◯） リポジトリ の分割ができる バージョニングができる 利用容易性（×） API を通した呼び出しになる バックエンド機能の共有には便利だが、フロントエンドコードの共有は難しい カスタマイズ性（◯） API のパラメータを変更することで振る舞いを変更可能 API を利用せず、独自実装を用いることで振る舞いを上書き可能 メンテナンス・拡張性（◯） API を拡張していく方式になる 影響 GitHub リポジトリ を新しく作り、その リポジトリ でパッケージング用のビルド スクリプト を書き、 GitHub PackagesにpushするCIフローを書く 公開の際のバージョニングの方法を別途検討する コンプライアンス 基盤コードの リポジトリ を分割し、その リポジトリ からパッケージを公開することで、 GitHub Pacakges(npm packages)経由での利用を案件側に強制することが可能。 基盤コードの リポジトリ についてはアクセス制限を厳密に実施する。 外部メンバーにはwrite, read程度の権限を付与し、mainブランチはブランチプロテクションで制限し、自分たちの知らないところで基盤コードを変更されないようにする。 基盤コードを案件開発者が閲覧し、案件コードにコピペすることは許容する。 参考情報 https://tech.dentsusoken.com/entry/2025/02/25/_%E8%A3%BD%E5%93%81%E3%81%AE%E3%82%A2%E3%83%89%E3%82%AA%E3%83%B3%E3%82%92%E5%AE%9F%E7%8F%BE%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E6%9C%80%E9%81%A9%E3%81%AA%E3%82%A2%E3%83%97%E3%83%AD%E3%83%BC 備考 別途案件カスタマイズ時の初期セットアップをサポートするために、Template リポジトリ を作りたい 執筆： @ozawa.hideyasu 、レビュー： @takami.yusuke （ Shodo で執筆されました ）

はいどーもー！ エンタープライズ 第一本部の宮澤響です！ 本記事では、私が運営チームリーダーとして運営を主導した弊社の社内イベントである「AHEAD AWARD 2024」についてご紹介します！ （イベントの詳細には社外秘の情報も含まれますが、当然そのような内容は記載できないため、全体的にあっさりめの表現となっています…ご容赦ください…！） （こんなイベントがあるんだな、こんな組織風土なんだな、というようなことを感じ取っていただけたら幸いです…！） （その意味では、弊社について情報収集している就活生やキャリア入社検討中の方向けの記事かなと思います…！） AHEAD AWARDとは？ どんなことをするの？ 運営チームリーダーをやってみての感想など おわりに AHEAD AWARDとは？ AHEAD AWARDとは、「弊社の 行動指針 である『AHEAD』を体現し、弊社や弊社のお客様への貢献度の高い活動を、社員投票によって選定する、社員による社員のためのアワード」とされています。 噛み砕いていえば、2024年に実施されたあらゆる活動の中から自薦形式でノミネートを募り、プレゼンテーションや全社投票を経て受賞活動を決定・表彰するイベントです。 そのため、2025年開催ではあるものの、イベント名はAHEAD AWARD 2024 となります。 なお、他社様においては、フューチャー株式会社の「Best Project of the Year」などが近しいイベントかなと思います。 どんなことをするの？ AHEAD AWARD 2024の大まかな流れは以下でした。 （内容は年々アップデートされていきますので、こちらはあくまで今回の内容です！） エントリー AHEAD AWARD 2024にエントリーする活動を、活動代表者の方からの自薦形式で募集します。 対象となる活動は上述のとおり2024年に実施されたあらゆる活動であり、対外的な有償案件だけでなく、自社内の施策や取り組みなども含まれます。 応募にあたっては、活動代表者の方にPRシートと呼ばれる資料を提出していただきます。 PRシートには、活動の概要やアピールポイントなどを記載していただきます。 ノミネート活動選定 運営チームなどが中心となって、エントリーされた活動の中からノミネート活動を選定します。 ノミネート活動に選定された活動は、これ以降の投票やプレゼンテーションに駒を進められます。 事前投票 ノミネート活動のPRシートやPR動画を公開し、全社投票を実施します。 社員のみなさまには、「AHEAD」を体現していると感じる活動に投票してもらいます。 プレゼンテーション ノミネート活動の代表者や関係者がプレゼンテーションを実施します。 プレゼンテーションはオンラインでも配信されるため、現地／オンラインを問わず視聴できます。 当日投票 プレゼンテーションを踏まえた上で、改めて全社投票を実施します。 PRシートやPR動画だけでは分からなかった長所や魅力が反映された投票となります。 表彰 事前投票と当日投票の票数を合算して、受賞活動を決定します。 AHEAD AWARD 2024では、Gold Prize、Silver Prize、Bronze Prizeの3つの賞がありました。 それぞれの賞を受賞した活動に対しては、トロフィーや副賞が贈呈されます。 後夜祭 最後は後夜祭と称した立食形式のミニパー ティー を開催します。 こちらはノミネート活動関係者に限らずどなたでも参加可能です。 弊社の社内同好会である 電通 総研Jazz部のみなさまによる生演奏も行われました。 運営チームリーダーをやってみての感想など まず第一に、運営チームメンバーやノミネート活動関係者のみなさまとの本部・事業部の枠を越えた繋がりができたことが大きな財産になったと感じています。 いわゆる通常の業務ではどうしても同じ部署のメンバーや同じ案件に携わっているメンバーとしか関わりがない状態になりがちなのですが、今回の活動を通して社内の垣根を越えた繋がりを構築できました。 また、弊社の活動を知る良い機会にもなったと感じています。 普段から他部署がどんなことをやっているのかを把握できているわけではなかったため、PRシートやプレゼンテーションなどを通じて他部署の活動内容を知ることができ、弊社全体の業務に対する理解が深まりました。 なお、現在はAHEAD AWARD 2025の運営メンバーに向けた引き継ぎ資料を作成中です。 というのも、AHEAD AWARDの運営チームは、リーダーやサブリーダーは前年の運営メンバーから選出されるものの、基本的にメンバーが毎年入れ替わります。 そのため、ただ開催して終わりというわけではなく、その後の振り返りや引き継ぎが重要となります。 このあたりも最後まできっちりこなしていく所存です。 おわりに 本記事では、弊社の社内イベントであるAHEAD AWARD 2024についてご紹介しました！ 本業の傍ら、このようなイベント運営にも手を挙げられるような働き方に興味がある、という方は、チラ見だけでも結構ですので、弊社の 新卒採用サイト や キャリア採用サイト をご覧いただければと思います。 最後までお読みいただき、本当にありがとうございました！ 私たちは共に働いていただける仲間を募集しています！ みなさまのご応募、お待ちしています！ 株式会社電通総研 新卒採用サイト 株式会社電通総研 キャリア採用サイト 執筆： @miyazawa.hibiki 、レビュー： @iwasaka.emari （ Shodo で執筆されました ）