こんにちは。BIGLOBEでSalesforceを利用した業務アプリケーション開発を担当している藤田です。 現在、BIGLOBEの開発チームでは「開発スピード2倍」を目標に掲げ、システム刷新や改善活動に取り組んでいます。 Salesforce開発に携わっている方なら共感していただけると思いますが、Salesforceはローコード/ノーコードの強みを活かし、画面上で設定を「ポチポチ」していくだけで素早く動くアプリケーションを作れるのが魅力のひとつです。 しかし、 「作るのは簡単だが、その変更点を設計書に反映する作業が非常に面倒」 という悩みはありませんか？ 実装スピードが上がれば上がるほど、ドキュメントの更新が追いつかなくなったり、転記ミスが発生したりしがちです。 そこで私たちは、Salesforceが提唱する 「ソース駆動型開発（Source-Driven Development）」 の考え方を取り入れ、Salesforce上のデータ（メタデータ）から設計書を逆生成することに挑戦しました。今回はその一例として、バッチ一覧を自動生成する仕組みをご紹介します。 システム構成：Salesforce CLIをドキュメント生成に応用する 実践：バッチ一覧の自動生成 こだわりの「リンク機能」 導入効果と今後の展望 まとめ システム構成：Salesforce CLIをドキュメント生成に応用する BIGLOBEでは、設計書をGoogleスプレッドシートで管理しています。そのため、Salesforceから取得した情報を最終的にスプレッドシートへ流し込むことがゴールとなります。 構築した自動化フローの全体像は以下の通りです。 １．データ取得（Node.js & Salesforce CLI）: まず開発PC上でNode.js製の自作プログラムを実行します。ここでポイントとなるのが、Salesforce CLI (SFDX) の活用です。これは本来、Salesforceが推奨するソース駆動開発においてデプロイ等に使われるコマンドラインツールですが、今回はこれを介してSOQLを実行し、必要な定義情報をデータとして取得しています。 ２．中間ファイル生成: 取得したデータを加工し、TSVファイルとしてGoogleドライブに保存します。 ３．反映: Googleスプレッドシートに仕込んだGoogle Apps Scriptを実行（ボタンポチ）し、ドライブ上のファイルを取り込んでシートに展開します。 実践：バッチ一覧の自動生成 具体的な活用例として、「フローバッチの一覧」を生成するケースを紹介します。 Salesforceにはバッチ実行の方法がいくつかありますが、今回は「Scheduled（スケジュール済み）」タイプのフローを取得対象としました。Node.js側のツールでは、以下のようなSOQLを発行してフローの定義情報を取得しています。 SELECT Id, FlowLabel, ApiName, Description, Type FROM FlowRecord WHERE Type = 'Scheduled' SELECT Id, CronJobDetail.Name, CronJobDetail.JobType, State, NextFireTime, PreviousFireTime, StartTime, CronExpression FROM CronTrigger WHERE CronJobDetail.JobType IN ('6','7') このようにメタデータへ直接クエリを投げることで、正確な定義情報を取得できます。これらを組み合わせ、スプレッドシートに出力した結果がこちらです。 バッチ名（論理名・物理名）やCRON形式の実行スケジュールが一目でわかるようになりました。 こだわりの「リンク機能」 この自動化において、開発者体験（DX）を向上させるために工夫したのが 「実装画面への直リンク」 です。 出力結果のB列にはURLが生成されており、ここをクリックするだけでSalesforce上の該当フローの実装画面へ即座にジャンプできます。ソースコード管理のアプローチを取り入れつつも最終的な確認は人間が行うため、設計書と実環境をシームレスに行き来できるこの機能は非常に便利です。 導入効果と今後の展望 今回紹介したバッチ一覧以外にも、同様の仕組みを使ってオブジェクト定義一覧やレポート一覧なども自動生成しています。 手作業での更新を廃止したことで、設計書の記述ミスがなくなり、常に最新の実装状態がドキュメントに反映されるようになりました。なにより、エンジニアが「文書作成」という非生産的な時間から解放され、より本質的な開発業務に集中できるようになったことが最大の成果です。 また、今後はこの機能を応用して 本番環境と開発環境のデータを取得・比較し、リリース前の変更箇所を洗い出す「環境間の差分チェック」 にも役立てていきたいと考えています。さらにはこれをCI/CDパイプラインの一部として組み込み、ソースコードレベルでの変更管理を徹底することで、より堅牢なDevOps体制を築いていきたいと思います。 まとめ BIGLOBEでは、このように「開発スピード2倍」という目標に向け、開発プロセスそのものの改善にも積極的に取り組んでいます。 Salesforce開発というと、SaaSの標準機能の枠組みの中での作業と思われがちですが、弊社ではCLIやスクリプト言語を組み合わせ、 「自分たちの開発環境は自分たちでコードを書いて良くしていく」 というエンジニアリング文化を大切にしています。 今後も、新しい技術やアイデアを積極的に取り入れながら、より効率的な開発環境を目指して改善活動を続けていきます。

「Gemini でアプリは作れるようになった。でも、社内で配る方法がない」 そんな課題を解消するために、Gemini Canvas で生成したコードをコピペするだけで、Apps Script プロジェクトを動的に生成・デプロイし、社内限定 URL を即時発行するツールを開発しました。 AI によるコード自動修正とAPIキーを隠蔽する仕組みにより、リリース1カ月で 200 以上の社内アプリを生み出した「サーバーレス・デプロイ基盤」を公開します。 はじめに Gemini Canvasの「配れない」ジレンマ 1カ月で200アプリを生み出した解決策 システムの概要 1. コピー＆ペーストでデプロイ 2. AIによるコード自動修正の提案 3. 公開設定とURLの発行 技術的な詳細と実装のポイント 1. Apps Script API による動的なプロジェクト操作 2. AIによるテンプレートリテラルの自動修復 3. フロントエンドへの認可機能の自動注入（API キーの隠蔽） 【前提】実行環境の制約と Google Cloud プロジェクト紐付け Step 1: Gemini APIを利用するサービスアカウントの作成 Step 2: 認可トークン発行ライブラリの作成 Step 3: デプロイ基盤による動的な依存関係の注入 まとめ はじめに AI 活用チームの高玉です。Google Apps Script で自作したツールが好評だったのでご紹介します。 Gemini Canvasの「配れない」ジレンマ 「自然言語で指示するだけで、動くアプリケーションが目の前で組み上がっていく」 Gemini Canvas は、ソフトウェアエンジニアでなくても自身のアイデアを即座に形にできる強力なツールです。特に素晴らしいのは、コード内に const apiKey = ""; と空文字を定義しておくだけで、実行環境が自動的にキーを補完し、Gemini API を呼び出せる仕組みです。 しかし、企業内で Google Workspace 環境を利用している場合、ある一つの壁に直面します。 「これ、どうやって社内共有する？」 Canvas上では動作していたアプリも、HTMLとして書き出すとAPIキーの自動補完機能は失われます。かといって、生のAPIキーをコードにハードコードして共有するのはセキュリティ上ご法度です。 つまり、「作る」ハードルは劇的に下がったのに、「安全に配る（公開・デプロイする）」ハードルは高いままなのです。 1カ月で200アプリを生み出した解決策 この課題を解決するために、 「Gemini Canvas で生成した HTML を貼り付けるだけで、裏側で Google Apps Scriptプロジェクトを動的に生成・デプロイするツール」 を開発しました。 社内ツールとして公開したところ、反響は凄まじく、リリースからわずか1カ月で200以上ものウェブアプリが社内で作成されました。 本記事では、このツールを支える技術的な裏側、特に Apps Script API を活用した動的なプロジェクト生成アーキテクチャと、AI 生成コード特有の課題を解決するための工夫について解説します。 システムの概要 このシステムは、ユーザーインターフェースとなる「管理用ウェブアプリ」と、その裏側で Apps Script API を操作する「バックエンドロジック」で構成されています。 操作はとてもシンプルです。 1. コピー＆ペーストでデプロイ Gemini Canvas で生成された HTML コードをコピーし、ツールの入力欄に貼り付けて「デプロイ」ボタンを押すだけです。 2. AIによるコード自動修正の提案 貼り付けたコードに Apps Script と互換性のない記述（テンプレートリテラル等）が含まれている場合、ツールが自動的に検知し、ワンクリックで AI に修正を依頼できます。 3. 公開設定とURLの発行 デプロイが完了すると、社内限定公開の URL が即座に発行されます。システム全体が Apps Script 上で完結していて、組織の Google Workspace 内で安全に共有できます。 技術的な詳細と実装のポイント ここからは、Apps Script に精通したエンジニア向けに、実装のポイントを解説します。 1. Apps Script API による動的なプロジェクト操作 通常はスクリプトエディターで記述する Apps Script プロジェクトを、プログラムから動的に生成します。 特に重要なのがデプロイに利用する projects.updateContent メソッドです。 developers.google.com 利用者の HTML を保存するだけでなく、ウェブアプリとして動作させるための doGet 関数やマニフェスト ( appsscript.json ) を JSON 構造として組み立て、API 経由で PUT します。 [Note] Apps Script API には 1日あたりの作成・更新回数の制限（Quotas） があります。通常の利用頻度では問題ありませんが、数百人が短時間に一斉にデプロイするような研修等で利用する場合はご注意ください。 [Note] 本ツールで生成された Apps Script プロジェクトは、実行したユーザー自身の「マイドライブ」に保存されます。 チームで永続的にメンテナンスする場合は、作成後にGoogle Drive APIを使って「共有ドライブ」へファイルを移動させることも可能です。こうすることで、退職等によるアカウント削除でアプリが消滅する「野良アプリ化」のリスクを防げます。 class AppsScriptApi { /** * プロジェクトのコンテンツを更新する */ updateContent ( appName , scriptId , htmlContent , isGeminiApiUsed ) { // 1. サーバーサイドのエントリーポイント（doGet） let codeGsContent = ` function doGet(e) { return HtmlService.createHtmlOutputFromFile('index') .setTitle(' ${ appName } ') .addMetaTag('viewport', 'width=device-width, initial-scale=1.0'); } ` ; // 2. マニフェスト（appsscript.json）の基本定義 const manifestContent = { timeZone : Session . getScriptTimeZone () , dependencies : {} , webapp : { executeAs : "USER_ACCESSING" , access : "DOMAIN" } , oauthScopes : [] } ; // 3. Gemini API 利用時の認可コード注入処理（後述） // ここで動的にライブラリ依存関係やフロントエンド用スクリプトを注入します if ( isGeminiApiUsed ) { this. injectGeminiAuth_ ( codeGsContent , manifestContent , htmlContent ) ; } const files = [ { name : 'appsscript' , type : 'JSON' , source : JSON . stringify ( manifestContent , null , 2 ) } , { name : 'Code' , type : 'SERVER_JS' , source : codeGsContent } , { name : 'index' , type : 'HTML' , source : htmlContent } ] ; // API経由でファイルを上書き return this. fetch_ ( `projects/ ${ scriptId } /content` , { method : 'put' , payload : { files } }) ; } } 2. AIによるテンプレートリテラルの自動修復 Gemini Canvas で生成される JavaScript コードは、ES6 のテンプレートリテラル ( ${...} ) を多用します。しかし、Apps Script の HtmlService において、 ${...} はバックエンドの 印刷スクリプトレット ( <?= ... ?> ) と構文解析上の競合を起こす場合があります。 そこで、利用者が貼り付けたコードにテンプレートリテラルを見つけると、Gemini API を呼び出して「Apps Script 互換の形式（文字列結合など）にリファクタリングさせる」機能を実装しました。 function fixHtmlWithGemini ( htmlContent ) { // Gemini APIへのプロンプト const prompt = ` ${ htmlContent } --- あなたはGoogle Apps Scriptの専門家です。 上記のHTMLコード内のテンプレートリテラル( ${ ... } )を、 Apps Scriptと互換性のある文字列結合などの形式に全て書き換えてください。 ` ; // ... Gemini API呼び出し処理 } 「AI が生成したコードの非互換性を、デプロイパイプラインの中で AI が自動修正する」ことで、ユーザー体験を損なうことなく問題を解決しています。 3. フロントエンドへの認可機能の自動注入（API キーの隠蔽） Gemini Canvas の魅力である apiKey="" のままで動く利便性を、公開アプリでも安全に再現する必要があります。 そこで「バックエンドで短命のアクセストークンを発行し、フロントエンドのリクエストに自動付与する仕組み」を構築しました。 この仕組みは、「認可トークン発行ライブラリ（GeminiAuth）」と、それを動的にアプリに組み込む 「デプロイ基盤（Publisher）」 の 2 つで構成されています。 利用者が Gemini API を利用するコードを貼り付けると、ツールはそれを自動的に検出し、以下のように「Google Cloud プロジェクトの設定」が必要であることを画面上で案内します。 さらに、利用者が迷わないよう、具体的な設定手順（Google Cloud プロジェクト番号の入力など）もモーダルで案内します。これにより、Apps Script に不慣れな人でもスムーズに設定を完了できます。 この裏側で動いている認可フローの全体像は以下の通りです。デプロイ時（静的解析と注入）と、実行時（動的なトークン取得）で役割を分担しています。 それぞれの実装詳細を以下に解説します。 【前提】実行環境の制約と Google Cloud プロジェクト紐付け Apps Script から IAM Service Account Credentials API のような権限の強い Google API を利用する場合は、デフォルトの管理プロジェクトではなく、新しく作成した Google Cloud プロジェクトを準備してその Apps Script に紐づける必要があります。ツールがユーザーに「プロジェクト番号の入力」を求めているのはそのためです。 なお、次に紹介する2つのステップで、それぞれ Google Cloud プロジェクトを作ります。上記の画面で利用者にプロジェクト番号の入力を求めていますが、（Step 2で作成する）認可トークン発行ライブラリーのプロジェクトであることに注意してください。 [Important] 請求先アカウント（Billing）の設定について Gemini APIを実行できるサービスアカウントを作るためには、対象の Google Cloud プロジェクトが請求先アカウント（クレジットカード等の支払い情報）にリンクされている必要があります。組織のポリシー等で課金設定ができない場合、この方法は利用できませんのでご注意ください。 Step 1: Gemini APIを利用するサービスアカウントの作成 まず、トークン発行の主体となるサービスアカウントを作成し、必要なAPIを有効化します。 Google Cloud プロジェクトの作成 : 課金アカウントにリンクされたプロジェクトを作成（または選択）し、以下の2つのAPIを有効にします。 Vertex AI API （IAM権限管理のため） Gemini API (Generative Language API) （実際のAPIコールのため） サービスアカウントの作成 : 「IAMと管理」>「サービスアカウント」から、新規サービスアカウントを作成します（例: gemini-executor@... ）。 IAM権限の付与 : 作成したサービスアカウントの「アクセス権を持つプリンシパル」に、このツールを利用する社員（または Google グループ）を追加します。 付与するロールは 「サービス アカウント トークン作成者 ( iam.serviceAccountTokenCreator )」 です。 [Important] セキュリティ上の注意 トークン発行用のサービスアカウントには、Vertex AI ユーザー 以外の権限（例: Storage管理者 や BigQuery管理者 等）を絶対に付与しないでください。 roles/iam.serviceAccountTokenCreator 権限を持つユーザーは、このサービスアカウントになりすますことができます。「最小権限の原則」を徹底し、意図しないリソースへのアクセスを防いでください。 [Tips] 全社員を個別に登録するのは管理コストが高いため、Google グループ（例: gemini-users@example.com ）を作成し、そのグループに対してこのロールを付与すると運用が楽になります。 Step 2: 認可トークン発行ライブラリの作成 利用者のアプリが共通して利用するトークン発行ロジックを、独立した Apps Script ライブラリとして作成します。 Google Cloud プロジェクトの作成 : GeminiAuth 用に任意のプロジェクトを作成し、IAM Service Account Credentials API を有効にします。 利用するサービスアカウントの指定 : スクリプトプロパティ SERVICE_ACCOUNT_EMAIL に Step 1 で作成したサービスアカウントのメールアドレスを保存しておきます。 認可ライブラリのコード（GeminiAuth）は以下のようになります。IAM Service Account Credentials API を呼び出し、Gemini API スコープを持つ短命アクセストークン（有効期限 15 分など）を取得します。 /** * Gemini API 用の短命なアクセストークンを生成する * @params {Number} lifetimeSec トークンの有効期限 [秒]。デフォルト 900 秒（15 分）。 * @returns {Object} { accessToken, expireTime } */ function fetchAccessToken ( lifetimeSec = 900 ) { // 事前にスクリプトプロパティに保存しておいたサービスアカウントのアドレス const serviceAccountEmail = PropertiesService . getScriptProperties () . getProperty ( 'SERVICE_ACCOUNT_EMAIL' ) ; const iamApiUrl = `https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/ ${ serviceAccountEmail } :generateAccessToken` ; const payload = { scope : [ "https://www.googleapis.com/auth/generative-language" ] , lifetime : ` ${ lifetimeSec } s` } ; const response = UrlFetchApp . fetch ( iamApiUrl , { method : "post" , headers : { "Authorization" : "Bearer " + ScriptApp . getOAuthToken () } , contentType : "application/json" , payload : JSON . stringify ( payload ) , muteHttpExceptions : true }) ; if ( response . getResponseCode () ! == 200 ) { throw new Error ( `Token generation failed: ${ response . getContentText ()} ` ) ; } return JSON . parse ( response . getContentText ()) ; } このスクリプトをライブラリとしてデプロイし、スクリプト ID を控えておきます。 Step 3: デプロイ基盤による動的な依存関係の注入 次に、利用者がアプリをデプロイする際、Step2で作成したライブラリを自動的にプロジェクトに追加するロジックを「Publisher」側に実装します。 Google Cloud プロジェクトの作成 : Publisher 用に任意のプロジェクトを作成し、Apps Script API を有効にします。 Apps Script Api を使ってデプロイするアプリの appsscript.json （マニフェストファイル）を書き換える際、 dependencies に先ほどの GeminiAuth のスクリプト ID を追加し、バックエンド ( コード.gs ) にはライブラリを呼び出すためのブリッジ関数を動的に追記します。最後に、フロントエンド側で window.fetch を上書きするスクリプトを HTML の <head> 内に強制注入します。これにより、フロントエンドの fetch リクエストが自動的に横取りされ、トークンが付与されます。 // Gemini API の利用が検出された場合の注入ロジック if ( isGeminiApiUsed ) { // A. マニフェストへのライブラリ依存関係の追加 manifestContent . dependencies . libraries = [{ "userSymbol" : "GeminiAuth" , "libraryId" : "..." , // GeminiAuth のスクリプト ID "version" : "1" }] ; // B. サーバーサイド(Code.gs)へのトークン取得関数の追記 codeGsContent += ` function getGeminiToken() { return GeminiAuth.fetchAccessToken(); } ` ; // C. フロントエンド(index.html)へのfetchフック処理の注入 const authHandlerScript = ` <script id="gemini-auth-handler"> (function() { // 後述 })(); </script> ` ; // HTMLの先頭にスクリプトを挿入 htmlContent = authHandlerScript + htmlContent ; } なお単純に毎回バックエンドにトークンを要求すると、 google.script.run の呼び出しに時間がかかり使い勝手が悪くなります。 そこで、このスクリプトでは次の工夫をしています。 キャッシュ管理 : 取得したトークンをメモリ上に保持し、有効期限内であれば再利用します。 プリフェッチ : ページが開かれた瞬間（ DOMContentLoaded ）に裏側でトークン取得を開始しておき、利用者が操作を始める頃にはトークンの準備を整えておきます。 Promise共有 : トークン取得中に複数のAPIリクエストが発生しても、APIコールは1回だけで済むようにPromiseを共有します。 // C. フロントエンド(index.html)へのfetchフック処理の注入 // トークンのキャッシュ管理とプリフェッチを実現するスクリプトを注入します const authHandlerScript = ` <script id="gemini-auth-handler"> (function() { let geminiAccessToken = null; let tokenExpireTime = 0; let fetchingPromise = null; // トークンを新規取得する関数（多重リクエスト防止付き） const fetchNewToken = () => { // 既に取得処理中ならそのPromiseを返す if (fetchingPromise) return fetchingPromise; fetchingPromise = new Promise((resolve, reject) => { google.script.run .withSuccessHandler(tokenInfo => { geminiAccessToken = tokenInfo.accessToken; // 有効期限より少し早め(例:30秒前)に切れ扱いにする安全マージン tokenExpireTime = new Date(tokenInfo.expireTime).getTime() - 30000; console.log("New access token acquired via server."); resolve(tokenInfo.accessToken); }) .withFailureHandler(error => { console.error("Failed to get access token:", error); reject(error); }) .getGeminiToken(); }).finally(() => { fetchingPromise = null; // 処理完了後にクリア }); return fetchingPromise; }; // 有効なトークンを返す関数（キャッシュがあればそれを使う） const getValidToken = () => { const now = new Date().getTime(); if (geminiAccessToken && now < tokenExpireTime) { return Promise.resolve(geminiAccessToken); } console.log("Token expired or missing. Fetching new one..."); return fetchNewToken(); }; // ページ読み込み時にトークンを先行取得（プリフェッチ）しておく window.addEventListener('DOMContentLoaded', () => { fetchNewToken().catch(e => console.warn("Token pre-fetch failed, will retry on request.")); }); // window.fetch をオーバーライド const originalFetch = window.fetch; window.fetch = async function(resource, options) { const requestUrl = resource instanceof Request ? resource.url : resource; // Gemini APIへのリクエストのみフック if (typeof requestUrl === 'string' && requestUrl.includes('generativelanguage.googleapis.com')) { try { // 有効なトークンを取得（待機またはキャッシュ利用） const token = await getValidToken(); const newOptions = { ...options }; newOptions.headers = { ...(newOptions.headers || {}), 'Authorization': 'Bearer ' + token }; // APIキーパラメータの削除 const urlObject = new URL(requestUrl); urlObject.searchParams.delete('key'); return originalFetch(urlObject.toString(), newOptions); } catch (error) { console.error("Authorization failed:", error); throw error; } } return originalFetch(resource, options); }; })(); </script> ` ; このアーキテクチャにより、API キーなしで Gemini API を呼び出せるという Gemini Canvas の恩恵を、そのまま享受できます。 まとめ 今回構築したシステムは、Apps Script を「API 経由で操作可能なサーバーレス・プラットフォーム」として捉え直すことで実現しました。 Apps Script API による動的な環境構築 AI によるコードの自動サニタイズ 動的なコード注入によるAPIキーの隠蔽 これらの技術を組み合わせることで、Gemini の優れた能力を最大限に引き出しつつ、社内ツール開発のハードルを劇的に下げることができました。 Apps Script は枯れた技術ですが、最新の AI 技術と組み合わせることで、まだまだ面白い使い方ができます。皆さんの組織でも、埋もれている「Canvas の力作」を救い出すツールを作ってみてはいかがでしょうか？

BIGLOBE では生産性ツールに Google Workspace を使っています。 最近、Google Chat や Gmail の画面に見慣れないアイコン（下の画像の赤丸部分）が増えたことにお気付きでしょうか？ 「これは何だ？」と思っていた方も多いかもしれません。その正体は 「Workspace Studio」 。Google Workspace の新しい自動化機能です。 この記事では、Workspace Studio の概要から、実際に Google Apps Script を使って「かゆい所に手が届く」自作アクション を開発するまでのプロセスを、試行錯誤の様子も含めてご紹介します。 なお、記事内で解説するスクリプトの完成版コードは記事の末尾にまとめて掲載しています。読み進める際はコードの全体像を気にせず、実装の流れを楽しんでいただければと思います。 2025/12/4 追記： プロダクト名がWorkspace FlowsからWorkspace Studioに変更されました。一部、古い記述が残っていますがご容赦ください。 workspaceupdates.googleblog.com .table-of-contents ul { display: none; } Workspace Studio とは？ テンプレートだけでは手が届かない「メンバー追加」の壁 Step 1. まずは Apps Script 単体で Chat API を試す 1. 事前準備（Google Cloud プロジェクトの準備、API 有効化など） 2. 実験コードを書く 3. 実行してみる Step 2. Studio のアクションとして実装する（まずは基本形） 重要：マニフェストファイル (appsscript.json) の設定 実装のポイント：変数の受け渡し 実装イメージ（Ver.1） やってみた結果……「機能はするが、もっと便利にしたい」 Step 3. Google Workspace の力を解き放つ（オートコンプリート実装） 改善策：PlatformDataSource を使う まとめ 付録 1：本記事の完成版コード 付録 2：JSONでUIを定義する 付録 3：トラブルシューティング・ガイド Q1. 実行するとエラーログに ReferenceError: Chat is not defined と表示される Q2. 承認画面で「権限を確認」へ進んだ後、「アクセスをブロック: 認証エラーです Some requested scopes cannot be shown: [https://www.googleapis.com/auth/chat.app.spaces]」と表示される Q3. 実行すると GoogleJsonResponseException: API call to chat.spaces.members.create failed with error: Google Chat API has not been used in project ... というエラーが表示される Q4. 実行すると GoogleJsonResponseException: API call to chat.spaces.members.create failed with error: Google Chat app not found. というエラーが表示される AI活用チームの高玉です。Google Workspaceの新機能、Workspace Studio を拡張して業務を楽にしてみました。 Workspace Studio とは？ 一言でいうと、「Google Workspace 上の面倒な定型作業を自動化してくれるすごい機能」です。 Workspace Studio では、自動化のプロセス全体を「Agent（エージェント）」または「Flow（フロー）」と呼びます。 Agent は、何かのきっかけで処理を開始する「Starter（スターター）」と、実際に行われる一連の処理である「Actions（アクション）」で構成されます。 Starter : 「毎日朝 9 時に」「メールを受信したら」「Google フォームが送信されたら」など Actions : 「メールを送る」「Chat に投稿する」「Gemini で要約する」など これらをノーコードでパズルのようにつなぎ合わせるだけで、業務を自動化できます。 特に、途中に Gemini や Gem を挟み込んで、生成 AI を使った要約や情報抽出ができるのが大きな特徴です。 テンプレートだけでは手が届かない「メンバー追加」の壁 さて、ここからが本題です。 私は社内で「LT 大会（ライトニングトーク大会）」などの勉強会を運営しているのですが、参加登録フローで一つ悩みがありました。 やりたいこと： Google フォームで「参加登録」があったら、その人を「勉強会参加者用の Chat スペース」に 自動的に招待（追加） したい。 Workspace Studio には「Google フォームの回答を受信時（Starter）」や「Chat にメッセージを投稿（Action）」という機能が標準で用意されています。 しかし、肝心の「指定したスペースにメンバーを追加する」というアクションが現時点では存在しません。 そこで、 カスタムステップ（自作アクション） を作って解決することにしました。 Step 1. まずは Apps Script 単体で Chat API を試す いきなり Workspace Studio のアクションを作りはじめる前に、まずは Apps Script 単体で「Chat API を使ってメンバーを追加できるか」を検証してみます。 1. 事前準備（Google Cloud プロジェクトの準備、API 有効化など） Apps Script から Google Chat API を利用するには事前準備が必要です。初めて使う方は、以前に書いた記事「Apps Script ではじめる🤖Google Chat アプリ開発ガイド（ユーザー認証編）」を参考にしてください。 style.biglobe.co.jp 全部で7つの手順が必要になります。Chat API はここが一番厄介ですね。作業漏れがあった場合に備えて、この記事の末尾に「トラブルシューティング・ガイド」を掲載しておきます。エラーが出た場合はそちらを参照してください。 作業 1. Google Cloud プロジェクトの作成 作業 2. Chat API の有効化 作業 3. OAuth 同意画面の構成 作業 4. Google Chat API の設定 作業 5. Google Apps Scriptを新規作成しプロジェクトの設定を変更する 作業 6. appsscript.json に oauthScopes を追加 作業 7. 高度なチャットサービスをスクリプトエディターで追加 なお、手順 6 の appsscript.json の oauthScopes ですが、 Chat.Spaces.Members.create() を使うので、 https://www.googleapis.com/auth/chat.memberships が必要になります。 { " timeZone ": " Asia/Tokyo ", " dependencies ": { " enabledAdvancedServices ": [ { " userSymbol ": " Chat ", " version ": " v1 ", " serviceId ": " chat " } ] } , " exceptionLogging ": " STACKDRIVER ", " runtimeVersion ": " V8 ", " oauthScopes ": [ " https://www.googleapis.com/auth/chat.memberships " ] } 2. 実験コードを書く まずはハードコードで動かしてみます。 公式ドキュメント「 ユーザー、Google グループ、Google Chat アプリをスペースに招待または追加する 」を参考に、次のようなコードを書きました。 なお、スペース ID は、Chat の URL https://mail.google.com/chat/.../space/AAAA... とは異なり、「s」がついている（ spaces/AAAA... ）ので注意してください。 /** * 実験用コード：指定したスペースに自分を追加してみる */ function testAddMember () { // 1. 追加先のスペースID // ブラウザのURLバーを確認し、"space/AAAA..." の部分を "spaces/AAAA..." に書き換えて設定します。 const spaceId = 'spaces/AAAAxxxxxxxx' ; // 2. 追加したいメンバーのID (今回は自分のメールアドレス) const userEmail = 'my-email@example.com' ; const payload = { member : { name : `users/ ${ userEmail } ` , // Chat API は 'users/{email}' 形式を要求する type : 'HUMAN' } } ; try { // Chat サービスの Spaces.Members.create メソッドを呼び出し const result = Chat . Spaces . Members . create ( payload , spaceId ) ; console . log ( '成功！メンバーを追加しました:' , result ) ; } catch ( e ) { console . error ( '失敗...' , e ) ; } } 指定したスペースに指定したメンバーを追加する関数ですが、今回はすでに参加済みのスペースに自分自身を追加します。なので動作結果に変わりはありませんが、API 呼び出しが成功するかどうかを確かめられます。 3. 実行してみる この関数を実行すると、実行ログに次のように表示されます。 成功！メンバーを追加しました: { name: 'spaces/***********/members/*********************', state: 'JOINED', member: { isAnonymous: true, name: 'users/*********************', type: 'HUMAN' }, role: 'ROLE_MEMBER' } 無事に Chat API の呼び出しが成功しました。もしエラーが表示される場合は、後述するトラブルシューティングをご覧ください。 これで「Apps Script から Chat API を呼び出してメンバー追加ができる」という確証が得られました。あとはこれを Workspace Studio のアクションに組み込むだけです。 Step 2. Studio のアクションとして実装する（まずは基本形） 実験でうまくいったロジックを、Workspace Studio から呼び出せる形にします。 Workspace Studio の拡張方法（Apps Script でのアクション作成）については、公式ドキュメント「 Google Workspace Studio を拡張する 」に詳細がまとまっています。 重要：マニフェストファイル ( appsscript.json ) の設定 コーディングに入る前に、この Apps Script プロジェクトが「Workspace Studio のアクション」であることを宣言する必要があります。 スクリプトエディタで appsscript.json を開き、以下のような addOns 設定を追加します。これにより、Studio 側からこのスクリプトが見えるようになります。 // ... (前略) "addOns" : { "common" : { "name" : "Chat Space Management" , "logoUrl" : "https://www.gstatic.com/images/icons/material/system_gm/1x/people_alt_black_24dp.png" } , "flows" : { "workflowElements" : [ { "id" : "addMemberToSpaceElement" , "name" : "Add Member to Space" , "description" : "Adds a user with the specified email address to a Google Chat space." , "workflowAction" : { // ... 入力パラメータや実行関数の定義 ... "onConfigFunction" : "onConfigAddMember" , "onExecuteFunction" : "onExecuteAddMemberToSpace" } } ] } } , // ... (後略) 実装のポイント：変数の受け渡し まずはシンプルに、「スペース ID」と「メールアドレス」を入力して実行するアクションを作ります。 ここでのポイントは、メールアドレスを手入力するのではなく、前のステップ（Google フォームの回答データ）から受け取れるようにすることです。 そのために setIncludeVariables(true) を設定し、変数の選択を許可します。 実装イメージ（Ver.1） Workspace Studio の設定画面（UI）を作る onConfig 関数です。 // Ver.1: テキスト入力だが、変数は選べるようにした設定画面 function onConfigAddMember ( event ) { // 1. スペースIDを入力させるテキストボックス const spaceInput = CardService . newTextInput () . setFieldName ( "spaceId" ) . setTitle ( "追加先のスペースID (spaces/...)" ) ; // 2. メールアドレスを入力させるテキストボックス // Googleフォームの回答（変数）を受け取れるように設定を追加 const emailInput = CardService . newTextInput () . setFieldName ( "email" ) . setTitle ( "追加するメンバーのメールアドレス" ) . setHostAppDataSource ( CardService . newHostAppDataSource () . setWorkflowDataSource ( CardService . newWorkflowDataSource () . setIncludeVariables ( true ) ) ) ; // ... (これらをCardに追加して返す) } やってみた結果……「機能はするが、もっと便利にしたい」 公式ドキュメント「 ステップをデプロイしてテストする 」にある通り、スクリプトエディターの右上にある「デプロイ」から「デプロイをテスト」> 「インストール」を選択すると、Workspace Studioのアクションに自作アクションが表示されるようになりました！画面右側の一番下にある「Add member to Space」です。 これで、メールアドレスはフォームの回答者情報を自動でセットできるようになりました。基本機能としては十分要件を満たしています。 [NOTICE] 記事執筆時点（2025年11月26日）では、メールアドレスの項目をGoogleフォーム内に明示的に作らないと、StudioのVariableとして取得できませんでした。今後の改善を期待しています。 ただ、実際に運用してみると 「スペース ID の入力」 に少し手間がかかることに気づきました。 Step 1 の実験でも触れましたが、スペース ID を入力するためにはブラウザの URL バーを確認し、 mail.google.com/chat/.../spaces/AAAAxxxx のような文字列から ID を特定してコピペする必要があります。 自分だけが使うなら問題ありませんが、他のメンバーにも気軽に使ってもらうには、もう少し直感的な操作にしたいところです。 Step 3. Google Workspace の力を解き放つ（オートコンプリート実装） そこで、Google Workspace の強みを活かした 「オートコンプリート（サジェスト）」機能 を実装し、さらに使いやすく進化させることにしました。 実は、Workspace Studio のカスタムステップでは、少しコードを書き換えるだけで、Google Workspace 上のデータ（スペース一覧やユーザー一覧）を検索候補として表示することができます。 改善策： PlatformDataSource を使う Apps Script のコードを修正します。 TextInput （テキスト入力）の代わりに、 SelectionInput （選択入力）を使用し、データソースに PlatformDataSource を指定します。 // Ver.2: オートコンプリート対応の設定画面 function onConfigAddMember ( event ) { // 1. スペース選択用ウィジェット (オートコンプリート) const spaceSelectionInput = CardService . newSelectionInput () . setFieldName ( "spaceId" ) . setTitle ( "追加先のスペース" ) . setType ( CardService . SelectionInputType . MULTI_SELECT ) . setMultiSelectMaxSelectedItems ( 1 ) . setPlatformDataSource ( CardService . newPlatformDataSource () . setHostAppDataSource ( CardService . newHostAppDataSource () . setWorkflowDataSource ( CardService . newWorkflowDataSource () // trueにすると、前のステップからの変数 ($変数名) を選択肢に含めます。 . setIncludeVariables ( true ) // Google Chat の「スペース」をオートコンプリートで検索できるようにします。 . setType ( CardService . WorkflowDataSourceType . SPACE ) ) ) ) ; // 2. メールアドレス選択用ウィジェット (オートコンプリート) const emailInput = CardService . newSelectionInput () . setFieldName ( "email" ) . setTitle ( "追加するメンバーのメールアドレス" ) . setType ( CardService . SelectionInputType . MULTI_SELECT ) . setMultiSelectMaxSelectedItems ( 1 ) . setPlatformDataSource ( CardService . newPlatformDataSource () . setHostAppDataSource ( CardService . newHostAppDataSource () . setWorkflowDataSource ( CardService . newWorkflowDataSource () . setIncludeVariables ( true ) // Google Workspace の「ユーザー」をオートコンプリートで検索できるようにします。 . setType ( CardService . WorkflowDataSourceType . USER ) ) ) ) ; // ... (Cardに追加して返す) } コードを更新して、再度 Workspace Studio の画面を開いてみます。 「追加先のスペース」をクリックすると、最近使ったスペースが候補として表示されるようになりました。「LT」と入力すれば、「LT大会」などのスペース名で検索できます。 これなら、スペース ID を意識する必要はありません。「どのスペースに」「誰を」追加するか選ぶだけで、とても便利です。 まとめ Workspace Studio は、標準のテンプレートだけでも十分に便利ですが、Apps Script と組み合わせることで真価を発揮します。 特に、今回ご紹介した PlatformDataSource を使ったオートコンプリート機能を使えば、ちょっとした手間で誰でも直感的に使えるツールになります。 皆さんも、「あと少し、ここさえ自動化できれば……」という業務があれば、ぜひカスタムステップの自作にチャレンジしてみてください。 付録 1：本記事の完成版コード 最後に、今回の記事で作成した Apps Script の全コードを掲載します。 appsscript.json（クリックで展開） { " timeZone ": " Asia/Tokyo ", " exceptionLogging ": " STACKDRIVER ", " runtimeVersion ": " V8 ", " dependencies ": { " enabledAdvancedServices ": [ { " userSymbol ": " Chat ", " serviceId ": " chat ", " version ": " v1 " } ] } , " addOns ": { " common ": { " name ": " Chat Space Management ", " logoUrl ": " https://www.gstatic.com/images/icons/material/system_gm/1x/people_alt_black_24dp.png " } , " flows ": { " workflowElements ": [ { " id ": " addMemberToSpaceElement ", " state ": " ACTIVE ", " name ": " Add Member to Space ", " description ": " Adds a user with the specified email address to a Google Chat space. ", " workflowAction ": { " inputs ": [ { " id ": " spaceId ", " cardinality ": " SINGLE ", " dataType ": { " basicType ": " STRING " } , " required ": true } , { " id ": " email ", " cardinality ": " SINGLE ", " dataType ": { " basicType ": " STRING " } , " required ": true } ] , " outputs ": [] , " onConfigFunction ": " onConfigAddMember ", " onExecuteFunction ": " onExecuteAddMemberToSpace " } } ] } } , " oauthScopes ": [ " https://www.googleapis.com/auth/chat.memberships " ] } コード.gs（クリックで展開） /** * Google Chat スペースメンバー追加エージェントの実行関数。 * (appsscript.json の onExecuteFunction から呼び出されます) * * @param {object} event - Workspace Flow Agent からのイベントオブジェクト。 * @returns {object | void} - 成功時はStudioに完了を通知する renderAction オブジェクト。失敗時は何も返さない。 */ function onExecuteAddMemberToSpace ( event ) { // 1. Studioから渡された入力値を取得 // Studioの入力は常に配列 (stringValues) として渡されます。 const inputs = event . workflow ?. actionInvocation ?. inputs ; const spaceId = inputs ?. spaceId ?. stringValues ?. [ 0 ] ; const email = inputs ?. email ?. stringValues ?. [ 0 ] ; // 2. 入力値のバリデーション if ( ! spaceId || ! email ) { console . error ( "必須パラメータ (spaceId または email) がありません。" ) ; console . error ( "受信した入力:" , JSON . stringify ( inputs )) ; // エラーが発生した場合、renderAction を返さないことで // Studio にこのステップが失敗したことを伝えます。 return; } console . log ( `メンバー追加処理を開始: Space= ${ spaceId } , Email= ${ email } ` ) ; // 3. Chat API 呼び出しのペイロードを作成 const membershipPayload = { "member" : { "name" : `users/ ${ email } ` , // Chat API は 'users/{email}' 形式を要求します "type" : "HUMAN" } } ; try { // 4. Chat API の呼び出し // Chat API Advanced Service (Chat) を使用します。 // spaceId は 'spaces/XXXX' という形式である必要があります。 // Studioから渡される値に 'spaces/' が含まれていない場合を考慮し、フォーマットします。 const formattedSpaceId = spaceId . startsWith ( 'spaces/' ) ? spaceId : `spaces/ ${ spaceId } ` ; console . log ( `Chat API 呼び出し: Chat.Spaces.Members.create (Space= ${ formattedSpaceId } )` ) ; // メンバーシップを作成（メンバーを追加） const newMembership = Chat . Spaces . Members . create ( membershipPayload , formattedSpaceId ) ; console . log ( "メンバーの追加に成功しました。" , newMembership ) ; // 5. Studio への成功応答 // 処理が正常に完了したことをStudioに通知します。 const renderAction = { "hostAppAction" : { "workflowAction" : { "returnOutputVariablesAction" : { // このエージェントは次のステップに渡す「出力変数」がないため、 // 空の配列を返します。 "variableValues" : [] } } } } ; console . log ( "Studioに成功のrenderActionを返します。" ) ; return renderAction ; } catch ( e ) { // 6. エラーハンドリング console . error ( `メンバーの追加に失敗しました。 Space: ${ spaceId } , User: ${ email } , Error: ${ e . message } ` , e ) ; // catchブロックでrenderActionを返さない（またはエラーをthrowする）と、 // Studioはこのステップが失敗したと認識します。 } } /** * 「メンバーをスペースに追加」エージェントの設定カードを生成します。 * (appsscript.json の onConfigFunction から呼び出されます) * * @param {object} event - Workspace Flow Agent からのイベントオブジェクト。 * @returns {Card} - CardService で構築された設定カードオブジェクト。 */ function onConfigAddMember ( event ) { // 1. スペース選択用ウィジェット (オートコンプリート) const spaceSelectionInput = CardService . newSelectionInput () // 実行関数(onExecute)に渡すためのID。appsscript.json の inputs.id と一致させる必要があります。 . setFieldName ( "spaceId" ) . setTitle ( "追加先のスペース" ) // Studioの変数ピッカー ($) と併用する場合、MULTI_SELECT のみサポートされます。 . setType ( CardService . SelectionInputType . MULTI_SELECT ) // 1つだけ選択させたい場合は、最大選択数を1に設定します。 . setMultiSelectMaxSelectedItems ( 1 ) . setPlatformDataSource ( CardService . newPlatformDataSource () . setHostAppDataSource ( CardService . newHostAppDataSource () . setWorkflowDataSource ( CardService . newWorkflowDataSource () // trueにすると、前のステップからの変数 ($変数名) を選択肢に含めます。 . setIncludeVariables ( true ) // Google Chat の「スペース」をオートコンプリートで検索できるようにします。 . setType ( CardService . WorkflowDataSourceType . SPACE ) ) ) ) ; // 2. メールアドレス選択用ウィジェット (オートコンプリート) const emailInput = CardService . newSelectionInput () . setFieldName ( "email" ) // appsscript.json の inputs.id と一致させる . setTitle ( "追加するメンバーのメールアドレス" ) . setType ( CardService . SelectionInputType . MULTI_SELECT ) . setMultiSelectMaxSelectedItems ( 1 ) . setPlatformDataSource ( CardService . newPlatformDataSource () . setHostAppDataSource ( CardService . newHostAppDataSource () . setWorkflowDataSource ( CardService . newWorkflowDataSource () // 前のステップからの変数 ($変数名) を選択肢に含めます。 . setIncludeVariables ( true ) // Google Workspace の「ユーザー」をオートコンプリートで検索できるようにします。 . setType ( CardService . WorkflowDataSourceType . USER ) ) ) ) ; // 3. セクションの作成 // 各ウィジェットをセクションに追加します。 const section = CardService . newCardSection () . setHeader ( "スペースと追加するメンバーを選択" ) . addWidget ( spaceSelectionInput ) . addWidget ( emailInput ) ; // 4. カードの構築 // セクションをカードに追加してビルドします。 const card = CardService . newCardBuilder () . addSection ( section ) . build () ; // 5. カードオブジェクトを返す // この戻り値が Studio の設定UIとして表示されます。 return card ; } 付録 2：JSONでUIを定義する Apps Script の CardService ビルダーメソッドを使用せず、JSONを直接記述することでUIを定義することもできます。詳しくは google.apps.card.v1 をご覧ください。 例えば、付録 1の onConfigAddMember は次のように書き換えることができます。 function onConfigAddMember ( event ) { return { // 4. カードの構築 (CardService.newCardBuilder().addSection(section).build()) "sections" : [ // 3. セクションの作成 (CardService.newCardSection().setHeader(...).addWidget(...)) { "header" : "スペースと追加するメンバーを選択" , "widgets" : [ // 1. スペース選択用ウィジェット { "selectionInput" : { "name" : "spaceId" , // setFieldName("spaceId") "label" : "追加先のスペース" , // setTitle("追加先のスペース") "type" : "MULTI_SELECT" , // setType(CardService.SelectionInputType.MULTI_SELECT) "platformDataSource" : { "hostAppDataSource" : { "workflowDataSource" : { "includeVariables" : true , // setIncludeVariables(true) — 前のステップからの変数を含める "type" : "SPACE" // setType(CardService.WorkflowDataSourceType.SPACE) — Chat スペースのオートコンプリート } } } } } , // 2. メールアドレス選択用ウィジェット { "selectionInput" : { "name" : "email" , // setFieldName("email") [3] "label" : "追加するメンバーのメールアドレス" , // setTitle("追加するメンバーのメールアドレス") "type" : "MULTI_SELECT" , // setType(CardService.SelectionInputType.MULTI_SELECT) "platformDataSource" : { "hostAppDataSource" : { "workflowDataSource" : { "includeVariables" : true , // setIncludeVariables(true) — 変数を含める "type" : "USER" // setType(CardService.WorkflowDataSourceType.USER) — Google Workspace ユーザーのオートコンプリート } } } } } ] } ] } } 付録 3：トラブルシューティング・ガイド Step 1 の Chat API テストでつまずきやすいポイントをまとめました。 Q1. 実行するとエラーログに ReferenceError: Chat is not defined と表示される A1. スクリプトエディターの「サービス」で、Google Chat API を追加してください。その際、ID（識別子）は Chat に設定してください。 Q2. 承認画面で「権限を確認」へ進んだ後、「アクセスをブロック: 認証エラーです Some requested scopes cannot be shown: [https://www.googleapis.com/auth/chat.app.spaces] 」と表示される A2. 設定が不足しています。特に、スクリプトエディターで appsscript.json を変更していない可能性が高いです（ appsscript.json を設定しない場合、 oauthScopes に https://www.googleapis.com/auth/chat.admin.memberships が自動的に設定されてしまい、Google Workspaceの管理者以外が利用できないエラーになります）。「 Apps Script ではじめる🤖Google Chat アプリ開発ガイド（ユーザー認証編） 」を参考にして、設定が不足していないか確認してください。 Q3. 実行すると GoogleJsonResponseException: API call to chat.spaces.members.create failed with error: Google Chat API has not been used in project ... というエラーが表示される A3. Apps Script に紐付けた Google Cloud プロジェクト側で、Google Chat API が有効化されていません。Google Cloud コンソールで API を有効にしてください。 Q4. 実行すると GoogleJsonResponseException: API call to chat.spaces.members.create failed with error: Google Chat app not found. というエラーが表示される A4. Apps Script に紐付けた Google Cloud プロジェクトで、Google Chat API の「構成」設定（Chat アプリの設定）が完了していません。設定してください。

プロダクト技術本部ネットワーク技術部の中野です。BIGLOBEのバックボーンネットワークの設計や構築を担当しています。 BIGLOBEでは、バックボーンネットワークに流入するDDoSトラフィックへの対策として、今回、新たにBGP Flowspec Redirect-to-IPと呼ばれる技術を導入し、DDoS Mitigationを実現するネットワークを構築しました。 今回は、BGP Flowspecの概要やRedirect-to-IPの動作概要などを紹介します。 BGP Flowspecとは BGP Flowspec Redirect-to-IPとは BGP Flowspec Redirect-to-IPの動作概要 おわりに BGP Flowspecとは BGP Flowspecは、2009年8月に RFC5575 として公開され、その後、2020年12月に RFC8955 にて改定されています。 このプロトコルは、BGPを拡張したもので、特定のトラフィック・フローに対するフィルタリングやアクションのルールをネットワーク内のBGPルーター群に動的に伝達するためのもので、主にDDoS攻撃対策を目的として開発されましたが、特定のトラフィックを識別して制御(帯域制限、リダイレクト、マーキングなど)するために幅広く活用されています。 BGP Flowspecの動作は、条件に一致したパケットに対して特定のアクションを実行するものとなっています。 条件は、以下のような単一の条件あるいは複数の条件を指定する事が可能で、BGPのNLRI(Network Layer Reachability Information)にて表現されます。 ポート番号等は、特定ポートに加えて、範囲指定なども可能となっています。 宛先Prefix 送信元Prefix IPプロトコル ポート番号 宛先ポート番号 送信元ポート番号 ICMPタイプ ICMPコード TCPフラッグ パケット長 DSCP値 フラグメント 条件に一致したパケットに対するアクションは以下のとおりで、BGPのExtended Communityを用いて指定します。 バイト/秒単位でのトラフィック量制限(0を指定すると破棄) パケット/秒単位でのトラフィック量制限 トラフィックアクション(後続のFlowspecの評価可否やサンプリング・ロギングの指定) VRFへのリダイレクト マーキング(DSCP値の上書き) この条件とアクションの組み合わせにより、例えば特定の宛先Prefixに対するトラフィックをバイト/秒単位で流量制限や、特定の送信元Prefixからのトラフィックを破棄するなど様々な制御が可能で、ACL(Access Control List)やPolicingなどの制御をBGPを用いて網内のルータに動的に配布を可能とする技術です。 BGP Flowspec Redirect-to-IPとは BGP Flowspec Redirect-to-IPは、BGP Flowspecのアクションを拡張するもので、BGP Flowspecの条件にマッチしたパケットを指定したIPアドレスに転送する機能です。 RFC8955 にて 規定されているアクションには、「VRFへのリダイレクト」はありますが、VRFを利用していないネットワークには適用しづらいという課題があり、リダイレクトをより簡単にするためにRedirect-to-IPアクションが検討されています。 現時点で、 BGP Flow-Spec Redirect-to-IP Action では「draft-ietf-idr-flowspec-redirect-ip-04」として、いわゆるInternet-Draftの段階のもので、仕様が確定していない技術となっています。 BGP Flowspec Redirect-to-IPの動作概要 今回導入したBGP Flowspec Redirect-to-IPの動作概要を簡単に紹介します。 下図のとおり、各ルータは外部との接続インターフェースにおいてFlowspecの制御を有効に設定(黄色の●の箇所)し、内部との接続インターフェースにおいてはFlowspecの制御を無効に設定します。 インターフェース毎にFlowspecの有効・無効に設定している理由は、ルータの両端でリダイレクトの処理が行われるとパケットがループしてしまうためで、パケットループを発生させないために内部との接続インターフェースにおいてはFlowspecの制御を無効にしています。 各ルータは、ネットワークに流れるトラフィックを一定の比率でサンプリングし、その情報をNetflow/sFlow/J-Flow/IPFIXなどの技術でフローコレクタに送信します。 フローコレクタは、送付されたフロー情報をもとにネットワーク上の異常トラフィックやDDoSの発生を監視します。 下図では、サーバに対して正規トラフィックとDDoS攻撃のトラフィックが流れている状況を記載しています。   フローコレクタは、DDoS攻撃を検知すると、攻撃対象を確認し、攻撃対象宛のトラフィックをDDoS Mitigation装置にリダイレクトするよう、各ルータに対してBGP Flowspec Redirect-to-IPの経路を広報します。   各ルータはBGP Flowspec Redirect-to-IPの条件・アクションに従い、トラフィックをDDoS Mitigation装置に転送します。 DDoS Mitigation装置は攻撃トラフィックを破棄し、正規トラフィックのみを元の宛先に向けて転送します。 フローコレクタはDDoS攻撃の停止を確認するとFlowspecの経路広報を停止し、各ルータは通常どおりのルーティングに戻ります。 このように、BGP Flowspec Redirect-to-IPを用いることで既存のネットワークを大きく変更することなく、トラフィックの柔軟な制御が可能となります。 ただし、BIGLOBEのバックボーンネットワークはマルチベンダーにて構成しており、今回導入したBGP Flowspec Redirect-to-IPは現時点でもInternet-Draftで、メーカー毎に参照しているDraftのバージョンが異なっておりプロトコル的に互換性がない状態となっています。 そのため、本技術のマルチベンダー環境への導入には、多くの課題と困難が伴いました。この課題解決に向けた対策は、2026年2月に開催される JANOG57 Meeting in Osaka にて発表しますので、ご興味のある方はぜひご参加ください。 おわりに BIGLOBEのバックボーンネットワークは、大量トラフィックのDDoS攻撃にも耐えうるように日々増強を進めていますが、DDoS攻撃が発生した場合でもお客様への通信についても安定してご利用いただけるように、今回紹介したDDoS Mitigationだけでなく様々な対策について取り組んで参りたいと思います。 最後まで読んでいただき、ありがとうございました。

こんにちは！BIGLOBEのAI分析推進部に所属している、2025年4月入社、新人のAです。 突然ですが、皆さんは「クラウド技術」にどのようなイメージをお持ちでしょうか？「難しそう」「どこから手をつければいいか分からない」と感じている方も少なくないかもしれません。 実は私も、ほんの数カ月前まではその一人でした。しかしこの度、入社後約5カ月という期間で、13個のGoogle Cloud認定資格を取得することができました。 この記事では、私のようなクラウド初学者だった新人が、どのようにして短期間で目標を達成できたのか、その具体的な学習戦略や活用した社内制度、そして資格取得で得た知識を日々の業務にどう活かしているかについて、余すところなくお話しします。 クラウド学習に興味がある方、これから資格取得を目指す方、そしてBIGLOBEのカルチャーに興味を持ってくださった方々の参考に、少しでもなれば幸いです。 ※本記事で紹介するのは、あくまで私個人のハイペースな挑戦です。この記事が皆さんにプレッシャーを与えることを意図するものではありません。ご自身の業務や学習スタイルに合わせて、最適なペースで学習を進めるための一つのサンプルとして、気軽に読んでいただけると嬉しいです。 取得した資格一覧 挑戦を支えたBIGLOBEの学習支援制度 1. Udemy Business 2. Eラーニング受講費補助 3. 資格試験の初回受験料無料 4. 合格時の報奨金制度 私のGoogle Cloud学習法 2つのポイント ポイント1：Udemy教材の徹底活用 ポイント2：Geminiに「なぜ？」を問い続け、理解を深める 短期間で成果を出すための効率化のコツ Associate資格も気を抜かない 関連範囲の資格はまとめて受験する 英語試験の文章量に注意 受験形式（オンサイト/オンライン）について おわりに 取得した資格一覧 まずは、今回取得した13個の資格を、私が感じた難易度とともにご紹介します。難易度は星の数で表しております。 資格名 言語 取得日 難易度（※個人の主観です） Associate Cloud Engineer 日本語 2025年05月11日 ⭐ Professional Cloud Architect 日本語 2025年07月29日 ⭐⭐ Professional Data Engineer 日本語 2025年08月07日 ⭐⭐⭐⭐ Professional Cloud Developer 日本語 2025年08月11日 ⭐⭐ Professional Cloud DevOps Engineer 日本語 2025年08月14日 ⭐⭐⭐ Professional Cloud Security Engineer 日本語 2025年08月17日 ⭐⭐ Professional Cloud Network Engineer 日本語 2025年08月21日 ⭐⭐⭐⭐⭐ Professional Machine Learning Engineer 日本語 2025年08月26日 ⭐⭐⭐ Professional Cloud Database Engineer 英語 2025年08月28日 ⭐⭐ Associate Data Practitioner 英語 2025年09月01日 ⭐⭐ Cloud Digital Leader 日本語 2025年09月02日 ⭐ Generative AI Leader 日本語 2025年09月02日 ⭐ Associate Google Workspace Administrator 日本語 2025年09月02日 ⭐ 挑戦を支えたBIGLOBEの学習支援制度 これだけの数の資格を、なぜ新人の私が短期間で取得できたのか。その最大の理由は、私個人の頑張りだけではなく、BIGLOBEの手厚い学習支援制度があったからです。 実際に私がフル活用させていただいた制度を、具体的な活用法と共にご紹介します。 1. Udemy Business BIGLOBEでは、オンライン学習プラットフォーム「Udemy Business」を法人契約しており、社員は対象講座を追加費用なしで自由に受講できます。クラウド関連の講座も非常に豊富で、私はまずここで各資格の全体像を掴むことから始めました。 2. Eラーニング受講費補助 Udemy Businessに対象講座がない場合や、より専門的な内容を学びたい場合でも、この制度が助けになります。個人で購入したオンライン教材の費用を会社が補助してくれるため、学習の選択肢が格段に広がります。 3. 資格試験の初回受験料無料 これが最も大きな後押しになった制度かもしれません。BIGLOBEでは、Google Cloud認定資格をはじめとする多くのIT資格の初回受験料を、全額会社が負担してくれます。1つあたり数万円することもある受験料を気にすることなく、「まずは受けてみよう！」と次々に挑戦できたのは、この制度のおかげです。 4. 合格時の報奨金制度 さらに、資格に合格すると会社から報奨金が支給されます。これは学習への直接的なモチベーションに繋がりました。「次の試験に合格したら、好きな食べ物を食べよう」といった具体的な目標を持つことができ、学習のサイクルを楽しく回し続ける原動力になりました。 これらの制度がなければ、金銭的にも精神的にも、5カ月で13個という挑戦は不可能だったと断言できます。BIGLOBEには、社員の「学びたい」という意欲を全力でサポートしてくれる文化が根付いていると感じます。 私のGoogle Cloud学習法 2つのポイント 会社の制度を最大限に活用しつつ、私が実践した具体的な学習法を2つのポイントに絞ってご紹介します。 ポイント1：Udemy教材の徹底活用 前述の通り、学習のベースはUdemyでした。私が教材を選ぶ際に意識していたのは、「レビュー評価の高さ」と「解説の丁寧さ」です。Udemyには玉石混交の教材があるため、購入前には必ずレビューに目を通し、特に「解説が丁寧」といったコメントがあるものを選ぶようにしていました。 模擬試験を何度も繰り返し解き、分からない部分はAIに聞いて復習する、というサイクルを徹底しました。 ポイント2：Geminiに「なぜ？」を問い続け、理解を深める 模擬試験で間違えた問題や、ブログを読んでも腑に落ちない概念に直面した時、私の最高の"壁打ち"相手になってくれたのが、Geminiをはじめとする生成AIです。 私が特に意識していたのは、「なぜこの選択肢が正解なのか」だけでなく、「なぜ他の選択肢は間違いなのか」を徹底的に言語化させることでした。 例えば、ある問題の正解が「署名付きURL」だった場合、ただそれを覚えるのではなく、Geminiに「この問題でIAMロールを使ってはいけないのはなぜ？」「公開アクセスとの違いは何？」といった質問を、自分が完全に納得できるまで投げ続けます。単なる暗記ではなく、各ソリューションのメリット・デメリットや使い分けを体系的に理解することができました。 短期間で成果を出すための効率化のコツ 次に、複数の資格を効率的に取得していくために、私が実践していたちょっとしたコツをご紹介します。 Associate資格も気を抜かない 「Associate」という名前から、入門レベルの簡単な試験だと油断してはいけません。問われる知識の範囲はProfessional資格と重なる部分が多く、問題文がシンプルである、という違いこそあれ、決して難易度が格段に低いわけではありません。 関連範囲の資格はまとめて受験する Google Cloudの認定資格は、それぞれが独立しているようで、知識範囲が重複しているものが多くあります。例えば、「Professional Cloud Developer」と「Professional Cloud DevOps Engineer」は、アプリケーションのライフサイクル全体をカバーしており、重複範囲が広いです。 このように関連性の高い資格は、期間を空けずに連続して受験することで、一度インプットした知識を最大限に活かすことができます。私も意図的に受験スケジュールを組み、知識がフレッシュなうちに次々と挑戦していきました。 英語試験の文章量に注意 一部、日本語に対応していない試験や、あえて英語で挑戦したい場合もあるかと思います。私も「Professional Cloud Database Engineer」は英語で受験しました。Professionalレベルの英語試験は、問題文や選択肢が長文になる傾向があります。技術的な知識があっても、長文読解に時間がかかってしまうと、時間切れのリスクが高まります。英語での受験を検討している方は、技術英語の長文を素早く正確に読み解く練習も並行して行うことをお勧めします。 受験形式（オンサイト/オンライン）について 受験形式には、テストセンターで受験する「オンサイト」と、自宅などで受験できる「オンライン」の2種類があります。 個人的には、PCやネットワーク環境が完全に整備されており、試験に集中しやすいオンサイト受験をお勧めします。 しかし、私のように短期間で多くの資格取得を目指す場合、テストセンターの予約が埋まっていて希望の日時に受験できないこともあります。スケジュールの都合で、オンライン受験を選択せざるを得ない場面も出てくるでしょう。 オンライン受験の際は、静かで誰も入ってこない個室と、PC内蔵または外付けのWebカメラが必須です。会社の貸与PCでは、セキュリティソフトなどの影響で受験できないケースがほとんどなので注意が必要です。また、机の上にはPCとマウス以外何も置けないなど、非常に厳格なルールが定められています。トラブルを避けるためにも、事前に公式サイトで要件をしっかりと確認してください。 おわりに 入社から5カ月間、無我夢中で駆け抜けてきました。13個という数字はあくまで結果ですが、この挑戦を通じて得られたGoogle Cloudに関する体系的な知識、そして「やればできる」という自信は、私にとって何物にも代えがたい財産となりました。 そして何より、このような挑戦を温かく見守り、応援してくれた上司や先輩、そして手厚い制度でサポートしてくれた会社には、感謝しかありません。 この記事が、これからクラウド学習を始めようとしている方、資格取得という目標に向かって頑張っている方、そしてBIGLOBEという会社に興味を持ってくださった方にとって、少しでもポジティブな刺激となれば、これ以上に嬉しいことはありません。 最後まで読んでいただき、ありがとうございました。

はじめに プロダクト技術本部の加藤（剛）と申します。 BIGLOBEは以前から生成AIを積極的に業務に活用しています。現状はクラウドサービスの生成AIを主軸に据えていますが、新しい技術や環境にも追随すべく、さまざまな検証を行っています。 先日、 こちら の取り組みを通じて日本HP社から、「NPU（Neural Processing Unit）処理が45TOPS以上の性能」を持つノートPC「 HP EliteBook X G1i 14 AI 」をお借りする機会をいただきました。 最近では、CPUメーカー各社もAI機能に注力しており、ノートPCでも「NPU処理が45TOPS以上の性能」を持つ製品が市場に出ています。では、この性能を持つNPUでローカルLLM（生成AI）を動作させることは可能なのか？もし動作するなら、どの程度実用的なのか？といった点は、エンジニアとして非常に興味を引かれます。 そこで今回は、手元のNPU搭載ノートPCを使い、今後の生成AI環境の選択肢となるであろう 「NPU＆ローカルLLM」の組み合わせで、実際に生成AI環境 を構築してみました。 なお、以下の内容は「 2025年6月末時点での情報 」をもとに作成しています。ご存知の通り、生成AI分野の技術進歩は目覚ましく、本日動作が確認できたとしても明日には状況が一変し、動作しなくなる可能性もあります。そのため、このような注意書きを記載させていただきます。 はじめに やりたいこと NPUでの開発環境 実装・その１：”intel-npu-acceleration-library” を利用 実装・その２：”OpenVINO” を利用 １）環境の構築 ２）LLM の準備 ３）実行コードを作成 ４）動かしてみる ５）実行結果 1. ルートヴィヒ・ウィトゲンシュタイン 2. ジャン＝ポール・サルトル 3. マルティン・ハイデッガー 【おまけ】 6）その他 さいごに サンプルコード やりたいこと 　まず、今回の「やりたいこと」は、先述の通り「NPUとローカルLLMの組み合わせの評価」なので、次の2つを目標に設定しました。 NPUでローカルLLM（生成AI）を動作させることは可能なのか？ その手法は？ を確認 NPUでローカルLLM（生成AI）を動かしたときのパフォーマンスはどの程度なのかを確認 →「NPUとローカルLLM」の組み合わせは、実際にどの程度利用可能なのか？ 　ところで、「NPU」と言ってもCPUを製造している各社が、それぞれの仕様でNPUを提供しています。今回はお借りしたノートPCに搭載されている「 Intel Core Ultra 7 プロセッサー 258V 」のNPUをターゲットとして話を進めます。 NPUでの開発環境 2025年6月時点でPCを使ってローカルLLMを試そうとした場合、最も手軽なのは「ollama」を利用することになるでしょう。しかし、調べたところollamaはNPUに対応していないとのことでした。そのため、別の方法を探す必要がありました。 調べた結果、Intel のNPUを利用してローカルLLMを稼働させる環境としてはいくつか存在していることがわかりました。例えば、以下のような環境が存在します。 intel-npu-acceleration-library OpenVINO DirectML 　最初の”intel-npu-acceleration-library”は、WindowsでPythonを利用する環境です。一方、”OpenVINO”は複数のOSに対応し、開発言語はPythonとC++を利用します。この2つはIntel社製の環境で、最後の"DirectML"は、名前の通りMicrosoft社が提供しています。 　これらのうち、私としては使い慣れた開発言語を利用したいので、Pythonが使える ”intel-npu-acceleration-library” か “OpenVINO” のどちらかでと考えました。ネットで少し調べると、”intel-npu-acceleration-library” のほうが簡単そうに見えたので、手始めに ”intel-npu-acceleration-library” から試してみようと思った…　のですが、これが苦悩の日々を始める原因にもなります。 実装・その１：”intel-npu-acceleration-library” を利用 　上で述べたとおりに、最初に ”intel-npu-acceleration-library” を利用してNPUでローカルLLMを稼働させようとしました。”intel-npu-acceleration-library”については以下のページで公開されています。 intel-npu-acceleration-library (GitHub) 　このページの下部に「Run a Tiny-llama model on the NPU」というサンプルコードがあります。ネットで ”intel-npu-acceleration-library” を調べると、日本語で書かれているものは大概、このサンプルコードを使っています。当然、私も最初にこのサンプルコードを動作させようと試みました。結果は…　 動きません！ 。このサンプルコードは、 そのままでは動きません 。GitHubの issue にも私と同じ状況になって困っている人がいました。 　では、このサンプルコードを動かすにはどうしたら良いのかというと サンプルコードを書き換える ”intel-npu-acceleration-library” ライブラリのコードを書き換える の2つの対応が必要になります。最初のは良いとして、2つめは「？」と思いますよね。実は、”intel-npu-acceleration-library”のページ（英文）を読むと Important Intel® NPU Acceleration Library – End of Life Announcement We are announcing the end of life for the Intel® NPU Acceleration Library. という記述があります。また、ページのトップには This repository was archived by the owner on Apr 25, 2025. It is now read-only. という記述があります。 要するに、”intel-npu-acceleration-library”は終了扱いで、2025年4月下旬からはメンテナンスもされていないということでした。このブログの最初に「いつ時点」かの注意を記載したのは、まさにこのためです。 私がPCを借りて”intel-npu-acceleration-library”を動作させようとした2025年6月時点では、すでに開発が終了したライブラリだったのです。一方で、ネットにある日本語の ”intel-npu-acceleration-library” の技術系記事は2025年4月よりもずっと前のものが多いので、これを参考にしても「うまくいかない」となります。 　結果として、サンプルコードが動かず、メンテナンス終了に気づくまでに 週末の2日間を費やしてしまいました 。 しかし、”intel-npu-acceleration-library”がこのような状況だと分かっただけでも収穫だと気を取り直し、別の環境で再挑戦することにしました。 実装・その２：”OpenVINO” を利用 　上記の通り”intel-npu-acceleration-library”が利用できなかったため、次に試したのは”OpenVINO”です。この環境は、2025年6月時点での IntelのCPU紹介ページに「OpenVINO」と名称が記載されているので、問題なく使えるだろうという予想で手を進めました。”OpenVINO” については以下のページで公開されています。 OpenVINO (GitHub） OpenVINO Documentation １）環境の構築 　とっかかりで使いだすのであれば、「OpenVINO Documentation」の「Install OpenVINO」から順にやっていく形になります。2025年6月時点で、”OpenVINO 2025.2” がリリースされていますので、こちらを使います。 　次にOpenVINOで生成AIを扱う場合には、「Generative AI workflow」あたりから読み進めていくことになります。うえで、‘‘OpenVINO 2025.2” の環境が出来上がっているかと思うので、ここでは "optimum-cli" コマンドを準備します。pipを使って以下のように実行します。 $ pip install optimum-intel[openvino] 余談ですが、実は私が勘違いして「pip install optimum-intel」と実行してしまい、正しいコマンドに気づくまでにかなり苦労しました。 ２）LLM の準備 　環境の構築が終わったら、次は生成AIのモデルの準備をします。「Generative Model Preparation」の中の「Convert and Optimize Generative Models」セクションに書いてある通りに、optimum-cli コマンドを使って目的の生成AIのモデルの変換をします。 optimum-cli コマンド自体が hugging face サイトから変換するLLMの元データのダウンロードをしてくれますし、事前に hugging face サイトからLLMのデータをダウンロードしているようなら、それを利用することもできます。いずれのケースでも、LLMの元データは (自分のホームディレクトリ) \.cache\huggingface\hub の下にあります。 optimum-cli コマンドのパラメータのうちで「weight-format」は「int4」を指定します。本当は「nf4」も試してみたかったのですが、NPUではnf4で変換したモデルが動かなかったため、早々に諦めました。 なお、OpenVINOで扱える生成AIのモデルで「最新＆日本語の精度が良い」のは「Phi-4」や「Qwen3」あたりになります。個人的には「Gemmaシリーズ」を試したかったのですが、動作対象ではない（optimum-cliのコードに記述がない）ようです。 ちなみに、「Phi-4」「Qwen3」が利用できるようになったのは、‘‘OpenVINO 2025.2”からなのですが、この ‘‘OpenVINO 2025.2”がリリースされたのが、2025年6月18日。ちょうど私が ‘‘OpenVINO” で悪戦苦闘していた期間だったりします。「optimum-cli のコードには「Phi-4」「Qwen3」とか書いてあるのに、‘‘OpenVINO”で動かんのは何故？」と悶々としていたら、たまたま見たリリースノートで「昨日の日付で‘‘OpenVINO 2025.2”がリリースされている？！」と気が付いたときに虚脱感と言ったら…。ということで、‘OpenVINO 2025.2”を入れたら、問題なく「Phi-4」「Qwen3」が動きました。ここにも、このブログの最初に「いつ時点」かを記載した理由があったりします。 さて、上記の通りにLLMの準備ができたら、次は実行コードを作成します。 ３）実行コードを作成 　今回は非常にシンプルなコードです。単に「モデルデータを読み込んでクエリ渡して回答を求める」程度のものです。今回作成＆実行した実際のコードはページの最後に記載しますが、単純に結果だけを求めるコードなら、この程度で済んでしまいます。 import openvino_genai as ov_genai model_path = "TinyLlama" pipe = ov_genai.LLMPipeline(model_path, "NPU" ) print (pipe.generate( "The Sun is yellow because" , max_new_tokens= 100 )) ただし、ローカルLLMは出力に時間がかかるため、ストリーミングで出力しないと現実的ではないでしょう。 ４）動かしてみる 　ページの最後に記載しているサンプルコードを、任意のファイル名で作成・保存します。 また、今回の評価で利用したモデルは「Phi-4:14b」になります。 サンプルコードは以下のようにいくつかのパラメータを渡すことで実行できます。「--device」でLLMの処理を CPU、GPU、NPU のいずれかで行うかを指定できます。「--debug」は true を指定すると決め打ちの質問をクエリにして実行します（処理時間計測用のオプションとして利用）。 $ python sample11.py phi-4 --device NPU --debug true 上記の指定の場合、あらかじめ用意された質問「20世紀の哲学者で著名な3名を理由も併せて回答して。」がクエリとして渡されます。実は、このフレーズは私のお気に入りで、ちょくちょく初めて使うローカルLLMでこのフレーズを使っています。 ５）実行結果 　では、実際にサンプルコードを実行した時の結果をお見せします。 　上記のように「--debug」を true にして「20世紀の哲学者で著名な３名を理由も併せて回答して。」の質問を推論させたとき、Phi-4の回答は以下のような内容になります。それなりにボリュームある回答をしてきます。 20世紀には多くの著名な哲学者が登場し、それぞれが哲学のさまざまな分野に大きな影響を与えました。以下に、特に著名な3人の哲学者とその理由を挙げます。 1. ルートヴィヒ・ウィトゲンシュタイン 理由 : ウィトゲンシュタインは20世紀の哲学において非常に影響力のある人物であり、特に言語哲学と論理学において重要な貢献をしました。彼の初期の著作『論理哲学論考』では、言語と現実の関係を分析し、論理的結果主義を提唱しました。後期の著作『哲学探究』では、言語ゲームの概念を導入し、言語の意味を社会的文脈に依存するものとして捉え直しました。彼の思想は、言語の役割と限界を理解する上で重要な基盤を提供しました。 2. ジャン＝ポール・サルトル 理由 : サルトルは存在論的人間主義の代表的な哲学者であり、特に存在主義の流れを決定づける役割を果たしました。彼の著作『存在と無』では、人間の自由と責任について深く掘り下げ、人間は自らの存在を通じて意味を創造するという考えを展開しました。また、サルトルは文学や政治にも深く関与し、哲学を超えて広範な影響を与えました。 3. マルティン・ハイデッガー 理由 : ハイデッガーは20世紀の哲学において最も影響力のある存在論者の一人とされています。彼の代表作『存在と時間』では、存在の問いを深く探求し、存在の「あり方」を「存在論的解釈」として捉え直しました。ハイデッガーの思想は、後の多くの哲学者や思想家に影響を与え、特に現象学や解釈学の発展に大きく寄与しました。 これらの哲学者は、それぞれ異なる分野で重要な理論を展開し、20世紀の哲学的議論において中心的な役割を果たしました。 　次にこの回答を出力するまでの経緯をお見せします。 　まず、サンプルコードを実行して、pipeを作成します。NPUで処理するための事前処理が実行されます。 cacheが効いている ときには、約1分程度の時間を必要とします。 pipeが作成されたら、それを利用してクエリを渡し、LLMの推論を実行します。このとき、NPUがどの程度稼働しているかをタスクマネージャーで確認したのが以下の図です。Phi-4程度のモデルサイズであれば、ローカルLLMの実行にはかなりのメモリが消費され、パフォーマンスも100%に近い値となります。なお、NPUのメモリはメインメモリと共有しているため、どちらかのメモリ利用量が大きいともう一方に影響が出ると考えられます。今回利用している 258V だとメモリ上限が32GBで、Phi-4のために必要なメモリが13GB弱となるので、その他のプログラムで利用するメモリはその辺の値を参考にして注意したほうがよろしいかと。 次に今回のPhi-4を使っての実行時間は以下の通りです。 前処理に要する実行時間が約1分13秒 推論に要する実行時間が約2分30秒 合計すると約3分40秒となり、正直なところ「終わるまで待つ」感覚は否めません。 　実は、これでも実行時間の短縮を図っていての値だったりします。上で「cacheが効いている」に下線を入れていますが、ここが実行時間の短縮を図っているところです。上の実行時間に記載した「前処理の実行」で行う内容をキャッシュできる機能があるそうです。以下はサンプルコードの一部を抜粋したものです。 pipe = ov_genai.LLMPipeline(model_path, device, CACHE_DIR= ".npucache" ) このように「CACHE_DIR」を設定すると、前処理の実行時間を短縮できます。では、このキャッシュが無い場合、どのくらいの差がでるのでしょうか。以下の図はキャッシュ無しの前処理を行った結果です。 上の通りに所要時間は2分ちょいとなります。キャッシュを効かせると、1回目の前処理は「2分ちょい」の時間を要しますが、2回目以降の実行で行われる前処理の所要時間は 「1分ちょい」と約半分近く短縮できることになります。とはいえ、前処理に1分以上かかるのは、実用的ではないと感じます。 ただ、これはPhi-4のサイズが、NPUで動かすには大きすぎるためかと思われます。以下は「Qwen3:4b」を実行した時の図です。 上のケースだと、キャッシュ無しでの実行となりますが、前処理の所要時間は 45秒 という値です。Phi-4のパラメータサイズは 14Bに対して、上の Qwen3のパラメータサイズは4bなので、この差によるものかと思います。Qwen3:4bは、起動から推論実行までを非常に軽快に動作させられます。 【おまけ】 今回の目的は「NPUでローカルLLMを動かす」ですが、同じコード、同じクエリをGPUで動かしたらどうなるのか？　以下がその結果です。 前処理で約22秒。 推論処理で1分5秒。 この結果を見ると、同じCPUに搭載されているGPUとNPUのどちらを使うかと聞かれれば、GPUを選んでしまいそうです。ただし、ここには「消費電力」という大事なパラメータが出てきていません。一般に NPUのメリットには「消費電力の低さ」があげられています。消費電力と処理時間とのかけ合わせで俯瞰したときに、NPUとGPUのどちらを選ぶのが最適になるのかは非常に気になるところだと思います。ただし、今回の評価環境ではNPUやGPUの稼働時の消費電力を調べる方法がなかったため、この点は評価から省かざるを得ませんでした。 6）その他 理由はわからないのですが、NPUを使って推論する場合、指定した最大トークン数に満たない時点で推論が終わるケースがあります。特に Qwen3 だとデフォルトで Thinking Modeで動くのですが、この Thinking Mode が長いとその途中で終わってしまうことが多々ありました。同じモデルとクエリで GPU上で稼働させたときには途中で終わることはないので、何かしらNPU側に制限があるのかもしれません。 さいごに 　Phi-4のような比較的大きなローカルLLMでも、NPUで動作することが確認できました。実際にPhi-4を使うには、現時点のNPUではややパフォーマンス不足だと感じます。一方、Qwen3:4b程度であれば、ストレスのないレスポンスで回答を得られるため、モデルを選べば「NPUとローカルLLM」の組み合わせは十分に実用的なレベルに達していると言えるでしょう。 　NPUについても、Intel社だけでなく、AMD社もCPUにオンパッケージでNPUを搭載しているAI対応CPUをリリースしています。NPUの性能（TOPS）的にはAMD社のNPUのほうが勝っているようなので、こちらも機会があれば評価してみたいと考えています。 サンプルコード # Generative LLM w/ Intel NPU #--- import datetime, os, argparse, logging from logging import FileHandler import openvino_genai as ov_genai logging.basicConfig( level=logging.DEBUG, format = "%(message)s" , datefmt= "[%X]" , handlers=[FileHandler(filename= "log.txt" )] ) def streamer (subword: str ) -> bool : print (subword, end= "" , flush= True ) def main (model_path: str , device: str , debug: bool ): print ( "Start main function." , flush= True ) 　pipeline_config = { "CACHE_DIR" : ".npucache" } st = datetime.datetime.now() print (f "---> モデル等の初期準備・開始時刻: {st}" ) if (device== "NPU" ): print ( "準備にしばらく時間がかかります。数分おまちください。 \n ---" , flush= True ) pipe = ov_genai.LLMPipeline(model_path, device, CACHE_DIR= ".npucache" ) elif (device== "GPU" ): print ( "準備にしばらく時間がかかります。 \n ---" , flush= True ) pipe = ov_genai.LLMPipeline(model_path, device, CACHE_DIR= ".gpucache" ) else : print ( "準備にしばらく時間がかかります。 \n ---" , flush= True ) pipe = ov_genai.LLMPipeline(model_path, device, CACHE_DIR= ".cpucache" ) et = datetime.datetime.now() t = et - st print (f "---> 準備処理・終了時刻: {et} （所要時間: {t}） \n ---" ) print ( " \n\n 開始します..." , flush= True ) if (debug): read_msg = "20世紀の哲学者で著名な３名を理由も併せて回答して。" st = datetime.datetime.now() print (f "---> 推論・開始時刻: {st}" ) print ( "--- \n 質問：" +read_msg) print (pipe.generate(read_msg, max_new_tokens= 32000 , streamer=streamer)) et = datetime.datetime.now() t = et - st print (f "--- \n ---> 推論・終了時刻: {et} （所要時間: {t}） \n ---" ) return while True : read_msg = input ( "質問を入力してください。： " ) if read_msg == " \\ q" : print ( " \n\n 終了します。" ) exit( 0 ) else : rslt_msg = pipe.generate( read_msg, max_new_tokens= 32000 , streamer=streamer) print () if __name__ == "__main__" : parser = argparse.ArgumentParser() parser.add_argument( "model_dir" , help = 'model_dir' ) parser.add_argument( "--device" , default= "CPU" ) parser.add_argument( "--debug" , default= False ) args = parser.parse_args() main(args.model_dir, args.device, args.debug)

こんにちは、BIGLOBEの松村です。 私たちBIGLOBEは、インターネットサービスプロバイダーとして、日々多くのお客さまと接点を持っています。その中で最も重要なのが、お客さまから寄せられる「生の声」です。しかし、電話やメール、メッセージなど、様々なチャネルに分散したお客さまの声を一つひとつ拾い上げ、サービス改善に繋げることには大きな課題がありました。 「お客さまの本当の気持ちを、もっと深く理解したい」 「データに基づいた客観的な事実で、サービスを改善したい」 そんな想いから、私たちはGoogle Cloudの生成AI「Gemini」を活用した 「お客さまの声・感情を可視化するシステム」 を構築しました。 本記事では、このシステムがどんな技術を使って生まれたのか、そして2025年3月の導入後に社内でどのような変化をもたらしたのか、そのリアルな道のりをご紹介します。 また、本記事内容は2025年8月5日～8月6日に開催された Google Cloud Next Tokyo で発表した内容になります。 01. 見過ごされていた「お客さまの声」 02. Geminiが可能にした「声の感情分析」と、その技術的裏側 システムアーキテクチャ：ニアリアルタイムな音声分析パイプライン 技術的挑戦と3つの工夫 技術ポイント①：精度とコストを両立する、階層的な音声認識戦略 技術ポイント②：プロンプトエンジニアリングによる、AIの採点能力の最大化 技術ポイント③：生成AIと従来技術のハイブリッドアプローチ 03. 導入から6ヵ月。AIへの不信から、データドリブン文化へ まとめ 01. 見過ごされていた「お客さまの声」 プロジェクト発足前、私たちは3つの大きな課題に直面していました。 外部調査で明らかになったCX（顧客体験）評価の低迷 膨大な量に埋もれ、見過ごされていたお客さまの声 部門ごとに情報が分断される、縦割り・サイロ化された組織構造 外部調査でCX評価が思わしくないことをうけ、私たちはまず、お客さまがサービスを認知してから利用、時には残念ながら解約に至るまでの一連の流れを「カスタマージャーニー」として可視化することから始めました。しかし、この取り組みによって、部門が縦割りになっており、サービス全体を俯瞰して見ている担当者が誰もいないという組織的な課題が浮き彫りになりました。各部門が協力してジャーニーマップを作成した結果、各フェーズで多数のお客さまの「痛点（ペインポイント）」が存在することが判明したのです。しかし、その声はあまりにも膨大で、手作業では集計・分析が追いつきません。結果として、どの痛点がより重要なのか優先順位をつけられず、多くのお客さまの声が見過ごされている状況でした。 そこで私たちは、AIによって膨大な量の音声データを自動でテキスト化・分析し、 応対品質の向上 と サービス改善の両輪でCX向上 を目指すことにしました。オペレーター一人ひとりの対応を客観的に評価すると同時に、これまで見過ごされてきた重要な「痛点」を定量的に把握することで、データに基づいた具体的なアクションに繋げるため、新たなシステムの開発をスタートさせました。 図1：システム導入による業務フローの変化 02. Geminiが可能にした「声の感情分析」と、その技術的裏側 このシステムの心臓部となるのが、Google Cloudの生成AI「Gemini」です。従来の音声認識サービスが抱えていた「話者特定の難しさ」「感情分析の不可」「高コスト」といった課題を、Geminiは解決してくれました。 特に画期的だったのは、 音声データを直接入力することで、テキスト化された内容だけでなく、声の抑揚やトーンから感情を分析できる 点です。これにより、私たちは従来のサービスと比較して 利用コストを約50%〜90%削減 しつつ、 音声認識成功率99% という高い精度を実現しました。 図2：Gemini活用による音声認識・文字起こしの進化 システムアーキテクチャ：ニアリアルタイムな音声分析パイプライン 本システムは、以下のGoogle Cloudサービス群で構成されており、音声データがアップロードされてから数分で分析結果が可視化される、ニアリアルタイムなデータ処理パイプラインを構築しています。 図3：お客さまの声・感情 可視化システム構成図 [入力] Cloud Storage : コールセンターシステムから出力された通話音声データが、通話終了の後、特定のバケットにアップロードされます。 [処理起動] Pub/Sub & Cloud Run : Cloud StorageへのファイルアップロードをイベントトリガーとしてPub/Subがメッセージを発行。これをサブスクライブしているCloud Runが起動し、音声ファイルごとの分析処理を開始します。このイベントドリブンなアーキテクチャにより、サーバーレスで効率的な処理実行が可能になっています。 [AI分析] Vertex AI (Gemini API) : Cloud Runのプログラムが、音声データをVertex AIのGeminiモデルに送信し、後述する3つの主要な分析（①文字起こし・感情分析、②応対品質採点、③カテゴリ分類）を実行します。 [データ格納] BigQuery : Geminiから返却されたJSON形式の分析結果（発話ごとのテキスト、話者、感情スコア、品質評価、カテゴリなど）は、構造化データとしてBigQueryのテーブルに格納されます。 [可視化] Looker / Looker Studio : 利用者は、BigQueryに接続されたLookerやLooker Studioのダッシュボードを通じて、常に最新の分析結果をインタラクティブに確認できます。 [監視] Google Chat : 処理中にエラーが発生した場合は、その内容が即座に開発者向けのGoogle Chatスペースに通知され、迅速な対応を可能にしています。 技術的挑戦と3つの工夫 開発においては、特に「精度」と「コスト」のトレードオフをいかに最適化するかが大きな挑戦でした。ここでは、その中心となった3つの技術的ポイントを深掘りします。 技術ポイント①：精度とコストを両立する、階層的な音声認識戦略 平均10分、長いものでは1時間を超える通話音声を、高性能なモデルで一度に処理するのはコスト的に非現実的です。そこで私たちは、性能とコストが異なるモデルを組み合わせる階層的なアプローチを採用しました。 1次処理 (コスト重視) : まず、低コストで高速なGemini 1.5 Flashモデルを使い、音声データ全体の大まかな文字起こしを試みます。 2次処理 (精度重視) : 1次処理で文字起こしが不完全だった場合、より高性能なGemini 2.5 Flashモデルでリトライ処理を行います。 この2段階の構成により、全体を低コストなモデルで処理し、必要な部分だけ高性能モデルを使うことで、コストを最適化しつつ音声認識成功率99%という高い精度を実現しました。 図4：コストと精度を両立する階層的な音声認識の仕組み 技術ポイント②：プロンプトエンジニアリングによる、AIの採点能力の最大化 オペレーターの応対品質をAIに評価させるため、評価項目（応対マナー、共感力など）、定義、評価例などを、AIが解釈しやすい マークダウンの表形式 でプロンプトに記述しました。さらに、約4万文字にも及ぶこの詳細なプロンプトは、Vertex AIの コンテキストキャッシュ機能 を利用することで、APIコストを約75%削減することに成功しました。 図5：AIによる応対品質レポートの生成プロセス 技術ポイント③：生成AIと従来技術のハイブリッドアプローチ お客さまの「痛点」を特定するカスタマージャーニー分析では、生成AIと従来の自然言語処理技術を組み合わせるハイブリッドアプローチを取りました。 Geminiの役割 (文脈理解・分類) : Gemini 2.5 Flashが対話全体の文脈を理解し、「申込手続き」「接続設定」といった大まかなカテゴリに分類します。 自然言語処理の役割 (集計・定量化) : カテゴリ分けされたテキストデータに対し、TF-IDFなどの従来手法を用いて特徴的なキーワード（ホットワード）を抽出・集計します。 この使い分けにより、生成AIの柔軟な文脈理解能力と、従来技術の厳密な集計・定量化能力の「良いとこ取り」を実現し、実用的なインサイトの発見に繋げています。 図6：生成AIと従来技術を組み合わせた痛点分析の仕組み 03. 導入から6ヵ月。AIへの不信から、データドリブン文化へ ツールの導入だけでは組織は変わりません。現場との対話を重ね、AIへの不信感を乗り越え、データに基づいた意思決定が当たり前になるまでの道のりがありました。 ① 導入当初（〜2ヵ月）：期待と不信の交錯 「実際のお客さまの声が聞ける」という期待の一方で、「AIの分析結果は信用できない」という根強い不信感がありました。まずは障害時の影響調査など、小さな課題解決で信頼を積み重ね、価値を実感してもらうことから始めました。 ② 転換期（2ヵ月〜）：現場への浸透と活用の模索 各担当者の課題に合わせて分析内容やLookerレポートを個別最適化するなど、現場に歩み寄ることで、「AIも使える」という認識が広まりました。社内報告書で本システムの分析結果が引用され始めるなど、変化の兆しが見え始めました。 ③ 現在（5ヵ月〜）：データドリブン文化の定着と自走 今では、現場担当者が特別なスキルなしでAIのチューニング（お客さま満足度の高いオペレーターの特徴をAIに学習させるなど）を行える専用アプリも開発して運用しています。お客さまの声を起点としたデータドリブンな施策が各方面で次々と生まれています。AIへの不信感は消え、誰もがデータに基づいて判断し、行動する文化が根付き始めています。 まとめ かつて私たちは、お客さまの声を十分に活かしきれていませんでした。しかし、生成AIの活用と、それを最大限に活かすための技術的工夫、そして現場との地道な対話を通じて、応対品質の向上とサービス改善のサイクルを確立し、お客さまの声を起点としたCX改善を推進するデータドリブンな文化を醸成することができました。 この取り組みはまだ始まったばかりです。これからもBIGLOBEは、データとテクノロジーの力で一人ひとりのお客さまに寄り添い、より良いサービスを提供し続けていきます。

BIGLOBEプロダクト技術本部の滝口です。 3年前にご紹介した 「モデルベースなネットワーク自動化への挑戦」 のその後の進展をお伝えします。 ネットワーク自動化への取り組み：沖縄オープンラボラトリとの共同研究 なぜ今、ネットワーク自動化が重要なのか？ 「モデルベース」による自動化の実現へ これまでの取り組みと成果 (2022年度～2024年度) BIGLOBEでの活用事例と今後のチャレンジ 1. ネットワークインターンシップでの活用 2. 商用環境への本格導入に向けたチャレンジ おわりに ネットワーク自動化への取り組み：沖縄オープンラボラトリとの共同研究 BIGLOBEは2021年より、 沖縄オープンラボラトリ (通称：OOL)の 「Model Driven Network DevOps Project」に参画しています。 伊藤忠テクノソリューションズ、NTTコミュニケーションズ(2025/7/1～NTTドコモビジネス)、TISと共に、 企業横断でネットワーク自動化の研究開発を進め、JANOGなどのカンファレンスや技術論文で成果を発表してきました。 なぜ今、ネットワーク自動化が重要なのか？ インターネットの通信量は年々1.1〜1.2倍も増加し※、仮想化やSDNといった分野での新技術の登場やサイバーセキュリティの重要性が増しています。これによりインターネット基盤はネットワーク装置を常に増設・増強しながら機能も高度・複雑化したことで従来の人手による運用では限界が見え始めています。この状況を打破するため、ネットワーク自動化は不可欠です。 ※ 我が国のインターネットにおけるトラヒックの集計・試算 の各回レポートを参照 Ansibleなどのツールで個々の機器に対する操作自動化は進んできていますが、ネットワーク全体で見たときの整合性を保証するのは困難です。「個々の設定が正しくても、ネットワーク全体としてこちらの意図した通りに動くとは限らない」これがネットワーク自動化の難しさです。この課題を解決するため、私たちOOLのProjectではネットワーク全体を俯瞰し、整合性を保つ自動化に挑戦しています。 「モデルベース」による自動化の実現へ 私たちは、IETF(インターネット技術の標準化を推進する団体)にて RFC8345 で定義されたネットワークトポロジーモデルを中心としたCI/CD（継続的インテグレーション/継続的デリバリー・デプロイメント）サイクルを構築することで、この課題を克服しようとしています。 CI/CDとは、ソフトウェア開発のリリースサイクルを自動化し、迅速で信頼性の高いデリバリーを目指す手法です。 この手法の成功には、自動テストと信頼できるテスト環境が鍵となります。 RFC8345とはYANG(ネットワーク機器の構成情報や状態をデータモデルで定義されるデータモデリング言語)を利用して、OSI参照モデルの各レイヤーのネットワーク構成図をデータモデルとして表現し、各レイヤー間の繋がりも表現できるモデルとなります。 RFC8345のネットワークトポロジーモデル ネットワーク分野ではテスト環境の準備が課題でしたが、 このRFC8345を用いたトポロジーモデルで商用環境のネットワーク構成を抽象化することでコンテナ仮想環境上に商用環境と同等のトポロジーを持つネットワーク構成を再現できるようになりました。この商用環境と同等のネットワークトポロジーを持つ仮想環境を 「ネットワークデジタルツイン」と名付け、 CI/CDサイクルに組み込む新しい運用コンセプトを提唱しています。 トポロジーモデルを介したネットワークデジタルツインのコンセプト これまでの取り組みと成果 (2022年度～2024年度) 2022年度、2023年度ではネットワークデジタルツインの中核となるトポロジーモデルに関して、日本のISP事業者のバックボーンのユースケースに対応させる試みを行いました。この試みにてOSPF、BGPに対応させ、検証網→商用環境といった形で実務レベルに拡張していきました。 2024年度では拡張したモデルを使って新しい運用のコンセプトとして、複数のデジタルツインを作ることで熟練運用者の脳内での試行錯誤をデジタルツインに置き換えて試行錯誤をデータモデルで網羅していくコンセプトを実証しました。 2022年度 (JANOG51) 「もし本番ネットワークをまるごと仮想環境に”コピー”できたらうれしいですか?」 NTTコミュニケーションズの検証網OSPF構成を対象にデジタルツインを構築するシステムを実装しました。 ネットワークデジタルツインを実現するシステム概要図 2023年度 (JANOG53) 「BIGLOBE AS2518をまるごと仮想環境へ”コピー”してみた」 JANOG51で実現したシステムをさらに拡張し、BIGLOBE商用環境の一部構成で デジタルツイン構築して過去運用事例の再現に挑戦しました。 ビッグローブでコピーした構成とオペレーション評価の概要 2024年度 (Okinawa Open Days) 「運用者の試行錯誤を想定したNWモデル上での並列検証システム」 今までネットワークデジタルツインが動作するコンテナ基盤を1台のVM上で動かしていました。このコンテナ基盤を複数台で起動できるように改善しました。これにより、複数のデジタルツインで熟練運用者の試行錯誤プロセス・ノウハウをデータモデルで表現するコンセプトを実証しました。 オペレータの試行錯誤プロセスを複数ネットワークデジタルツインで表現する検証 BIGLOBEでの活用事例と今後のチャレンジ 1. ネットワークインターンシップでの活用 昨年の8月に 就活生向けにネットワークエンジニア業務体験 を開催しました。 この業務体験に向けてBIGLOBEのISPバックボーン構成を簡略化したNW構成を用意しました。 1環境でルータ7台、サーバ8台で構成しており、これを10環境複製する必要がありました。 この規模を物理機器や仮想マシンベースで用意しようとすると、機材費用や構築工数がかかるため、環境構築が容易ではありませんでした。 そこで、JANOG53でのBIGLOBEの商用環境のデジタルツインを構築したノウハウを使うことでAWSのEC2インスタンス10台のリソースに抑え、設計・構築工数も2ヵ月程度の短期間に短縮することができました。 これによって、ISPバックボーンの実践的な基盤運用を学生17人に体験してもらうことができました。 ネットワークインターンで用いたネットワーク構成 2. 商用環境への本格導入に向けたチャレンジ OOLでの成果をBIGLOBEの商用環境へ適応するためには、大きな課題があります。 Batfish依存問題の解消 OOLではネットワーク機器の構成情報を抽出するツールとして Batfish を主に利用しています。Batfishは、サポート対応機種に関してはコンフィグ解析機能が使うことができるツールとなりますが、Batfishが対応していないベンダーおよびプロトコルに対する拡張が課題となっておりました。BIGLOBEでは現在導入を始めている NOKIA のルータに対してもこの課題に直面しております。(2025年5月末時点で未サポート※)。NOKIAルータのコンフィグ解析及び、 Netbox 上で構成管理する機能の実装から着手し、Batfish非対応のベンダー機器でもネットワークデジタルツインが実現できるように拡張を進めています。 ※ https://github.com/batfish/batfish/issues/3047 構成管理ツールのNetbox上におけるNOKIAルータのInterface一覧画面 この課題を解決したノウハウをもとに、BIGLOBE商用環境への本格導入を推進して モデルベース中心のネットワーク運用自動化を実現したいと考えています。 おわりに BIGLOBEは、これらの挑戦で得た知見をOOLの活動へフィードバックし、ISP業界全体のネットワーク運用自動化の発展に貢献していきます。今後のBIGLOBEの取り組みにご期待ください。 ※ 掲載されているイラスト、写真に関する著作権はBIGLOBE又は第三者が有し、許諾なく利用できません。 ※ 沖縄オープンラボラトリおよびOOLは、一般社団法人沖縄オープンラボラトリの名称です。 ※ JANOGは、JApan Network Operators' Groupの名称です。 ※ IETFは、Internet Engineering Task Forceの名称であり、インターネット技術の標準化を行う活動およびそのコミュニティを指します。 ※ YANGは、IETFによって標準化されたデータモデリング言語の名称です。 ※ Batfishは、オープンソースのネットワーク検証ツールです。 ※ NetBoxは、NetBox Labsのオープンソースのネットワーク管理ツールです。

開発部署で始まった読書会に参加した体験記です。「ドメイン駆動設計をはじめよう」を読み解く過程で、チームで議論し理解を深めることができました。読書会を通じて得た気づきについてご紹介します。 読書会の流れ 読書会に参加してみて よかったこと イマイチなところ まとめ おわりに こんにちは、開発部門（プロダクト技術本部）の嶋崎です。 私たちの部署で若手メンバーを中心とした読書会が始まり、参加する機会がありました。 書籍「ドメイン駆動設計をはじめよう」（著：Vlad Khononov、訳：増田 亨、綿引 琢磨、出版：オライリー・ジャパン）を題材に、全15回にわたって実施した読書会の進め方と得られた学びについて紹介します。 ドメイン駆動設計（DDD）は、ソフトウェア開発において複雑なビジネスロジックを整理し、より良い設計を行うための手法として知られています。 書籍自体は従来のドメイン駆動設計に関する書籍と比べても読みやすい部類に入ると思いますが、 そうは言っても抽象的な概念も多く含まれるため、書籍を読んだだけではなかなか理解しづらい部分もあるのも事実です。 この記事が同様の取り組みを検討されている方や、組織内での知識共有の場づくりに悩んでいる方の参考になれば幸いです。 読書会の流れ 全15回にわたって開催されました。週に1時間、カレンダーに時間を確保し、都合のつくメンバーが参加するようにしました。 読書会では事前準備は不要で進め、その回ごとに一緒に読み進めていくスタイルで進行しました。 読む範囲はおおむね書籍の章ごとに分割して、ボリュームのある章は複数回に分けました。 1時間の流れは大きく2つのパートに分けて進行しました。 前半30〜40分 指定された範囲を各自で読みながら、気づきや疑問をホワイトボードツールに書き出す 後半20〜30分 書き出した内容をもとに、参加者同士で話し合う 今回はホワイトボードツール( draw.io )を使って情報を共有しました。読みながら気づいたこと、疑問点、関連する経験などを自由に書き込みます。 書くためのルールは設けず、思いついたことをそのまま記録するようにしました。後半は書き出された内容を元に、質疑応答を進めていくといった感じです。 読書会に参加してみて よかったこと その場で読んだ後にすぐに参加者同士で話せて楽しい 読んでいて疑問や気になる箇所を共有したことで、他の参加者の解釈やアドバイスがもらえました。 DDDに詳しい有識者や過去のシステムで実践したときの失敗談など実際に体験したエピソードから、話が盛り上がりました。 チーム内の共通言語の形成 読書会で学んだ内容について共通認識があるため、実際の業務でも「あの本で出てきた〇〇の考え方」と参照しやすくなったり、書籍の内容をベースとした議論がありました。 イマイチなところ 進捗が遅い その場で読み進めるスタイルのため、全15回と長期間を要しました。短期間で知識を得たい場合には向いていないです。 参加者のスケジュール調整が難しい 毎回全員が参加できるわけではなく、欠席者へのフォローが課題となりました。それが参加者のモチベーション低下につながることもありました。 議論の深さにムラがある 本の内容と読書会のスタイルの特性もあり、読む章によっては議論が活発になる部分とそうでない部分があり、工夫が必要だと感じました。 まとめ ドメイン駆動設計（DDD）は 概念的で抽象的な内容が多いため一人で読むと「なんとなく理解した」という曖昧な状態で終わりがちになると思いませんか。 読書会形式で進めることで、効果的に理解を深めることができたと思います。また、普段の業務では関わらないメンバーとも会話することで、技術的な議論ができる場として機能し、単に知識を得るだけでなくチームとしての共通言語や土台を築けたことも収穫でした。 おわりに 読書会を通してDDDという難解な概念を楽しみながら学ぶことができました。 最初から完璧な読書会を目指すのではなく、まずは気軽に始めてみて続けていくために自分たちに合ったスタイルを見つけていくことが大切だと思います。 最後まで読んでいただき、ありがとうございました。

皆さん、こんにちは。 プロダクト技術本部の穂積です。 本日は、2023年9月に完了した、自営のデータセンターからAmazon Web Services（AWS）への移行についてお話したいと思います。 以前、下記ブログでも紹介しましたが、今回はもう少し深堀りしてご紹介します。 style.biglobe.co.jp 始まり 移行の目的と期待する成果 移行計画 移行の全体計画概要 使用したアプローチ 移行前の評価と準備 評価と準備のポイント 実行 移行の反省と対策 基幹データベース移行の挑戦 完了後の評価 移行が成功した要因 最後に 始まり 事の起こりは2018年6月に遡ります。 弊社では、長年にわたり自営のデータセンターを運営していました。しかし、そこでの運用は多くの課題を抱えており、改善が求められていました。 一方で、その当時は、通信事業者や信頼性が重要視される金融系業界でもクラウド化の波が押し寄せ始めており、新技術を活用したサービスが次々と展開されていました。こうした変化を目の当たりにし、我々も新しい時代に対応するためのインフラを構築する必要があると考えました。 そこで採用したのが、「AWSファースト」戦略です。この戦略のもと、私たちはAWSに移行することを決定しました。 「AWSファースト」とは？ 新規システム AWSでのインフラ構築を原則とし、自営のデータセンターでの構築は行わない 既存システム リニューアルのタイミングで順次AWSに移行 移行の目的と期待する成果 移行の目的は、やはり事業環境の変化に柔軟かつ迅速に対応できる新しいインフラ環境を手に入れることです。 期待した成果は以下のとおりです： コスト面: 変動費型の事業基盤への移行により、利用状況の変化に柔軟に対応 サービスごとのコスト見える化 インフラ/開発コストの削減 デリバリ: ハードウェア / ソフトウェアの購入・構築なしでタイムリーに準備 新機能リリース期間の短縮 投資回収期間の短縮 品質と生産性: 耐障害性向上 構築自動化による生産性向上 レガシーからAWSマネージドサービスへ移行 エンジニアリング: クラウドネイティブへシフト 最新のクラウド機能をビジネスへ組み込み クラウドノウハウの蓄積と共有 このような数々の利点を見据えて、私たちはAWSへの移行を進めました。 このブログを通して、移行のプロセスやその後の成果を皆さんに共有できればと思います。 移行計画 移行の全体計画概要 まず初めに、システム移行の順序を計画するにあたり、移行難易度を整理しました。 計画の基本方針として、比較的容易に移行できるシステムから順次AWSへ移行を進めていくこととしました。 新規システム これらは最初にAWS上で構築されることが前提です。 既存システムで他のシステムと連携していない、規模が小さいシステム 独立度が高く移行しやすいため、早期の移行対象としました。 既存システムで他のシステムと連携しているが、大規模ではないシステム 少々複雑ではあるものの、比較的迅速に対応可能です。 既存システムで他システムと密に連携していて、大規模なシステム こうしたシステムは移行の中で最も難易度が高く、慎重に進める必要がありました。 会員基盤などの基幹システムは4番目に分類され、監視システムなど自営のデータセンターに残さざるを得ないものを除き、最終的にはすべてAWSへ移行していく計画です。 使用したアプローチ 移行方針として採用したのは「リフト＆シフト」です。これは、迅速な移行を最優先にし、移行後にAWS向けの最適化を進める方法です。 リフト＆シフトのリフト時点では、通常アーキテクチャを自営のデータセンターのものと同じくすることが多いですが、弊社ではいくつか次のような置き換えを行いました。 データベースはAWS RDSに置き換え データベースの管理効率とスケーラビリティを向上させるためです。 ドメインはRoute53に置き換え ドメイン管理を一元化することで、シンプルな運用を実現しました。 ログ保存はCloudWatchLogsとS3に置き換え ログ保存場所の統一とデータの永続性を強化しました。 他にもいくつかありますが、これらの変更は、置き換える際のコストとその後に得られるメリットを十分に考慮した結果です。 このようにして、慎重かつ計画的にAWSへの移行を進めました。 移行前の評価と準備 AWS移行プロジェクトの準備段階についてご紹介します。大規模な移行を成功させるためには、入念な準備が必要不可欠です。 評価と準備のポイント 移行前に行った評価や準備は、以下の通りです。 1. クラウドへの理解を深める 社内で有志による勉強会を開催し、クラウドの基本を学びました。また、ユーザー会（JAWS）に積極的に参加し、外部からの情報を収集しました。さらに、AWS最大のイベントであるre:Inventにも参加し、クラウドの未来を実感しました。 2. 戦略策定と役員の賛同を得る 「AWSファースト」戦略を立案し、コスト試算を行いました。中期計画としてこれを全社で推進するため、役員の賛同を取り付けました。 3. CoEの組織と準備 AWSのコンサルタントの協力を得て、他社の成功事例から学びました。そして、社内にクラウド移行の中心となるセンターオブエクセレンス（CoE）を組織しました。クラウド移行用に社内の既存の規定を再整備し、その規定に沿ったクラウド基盤を整備しました。移行計画も各システムの担当者と共有しました。 実行 移行の反省と対策 移行初期、比較的移行が簡単だと考えていたシステムを半年間で40ほど移行する計画を立てました。しかし、実際に移行できた数はわずか8システム。目標を大きく下回りました。この失敗の主な要因は、準備不足と甘い計画にありました。 1. 準備不足の露呈 初期の移行段階では、準備の甘さが顕在化しました。十分に整備したつもりのクラウド基盤でしたが、作業手順の作成漏れや、想定外の作業が多発しました。さらに、依頼者と作業者の間での意思疎通が不十分だったため、手戻りが多発しました。 対策として、自営のデータセンター時代の作業を洗い直し、すべてに対応できるよう作業手順を見直しました。また、担当者間の意思疎通を円滑にするため、調整役をアサインしました。 2. スケジュール管理の不備 初期のシステム移行では、各担当者に任せることでスケジュールにばらつきが生じ、構築やセキュリティアセスメント担当者への依頼が集中してしまいました。 解決策として、構築からリリースまでの各工程を具体的な日程に落とし込み、それを基に担当者と合意形成を図りました。これにより、負荷の集中を避けることができました。 3. 関係者とのコミット不足 AWS移行に関する合意は得ていたものの、急な開発案件や障害対応でリソースが他に割かれ、移行が滞ることが度々ありました。これに対しても、スケジュールの厳密な管理と、進捗状況の継続的なヒアリングを実施し、さらに各担当者の上司にもスケジュールに合意してもらうことでリスクを軽減しました。 これらの反省を基に、次年度には計画を大きく上回る80システムの移行を達成し、プロジェクトの軌道修正に成功しました。スケジュール管理の重要性と、移行のための準備の徹底がいかに大事か、深く学んだ日々でした。 基幹データベース移行の挑戦 その後、順調に移行が進みました。しかし、最終段階では、関連システムが多く存在する基幹データベースの移行という大きな壁が待ち受けていました。この移行は、すべてをメンテナンス時間内に完了させる必要があり、かつ管理者不在の関連システムの存在やテラバイト級のデータ量の移行など多くの課題がありました。 評価環境でのリハーサルを1回、本番環境では2回の移行リハーサルを実施しましたが、初回の本番移行は権限設定の移行漏れで失敗。しかし、2回目で改善し、無事に成功を収めました。この過程で、多くのエンジニアが深夜にも関わらず尽力してくれたことに、心から感謝しています。 また、データ移行にはAWS Database Migration Service（DMS）とexpdp/impdpを併用しました。当初はAWS DMSのみでの移行を考えていましたが、様々な課題に直面し、併用する選択をしました。本データ移行は、株式会社システムサポート様に多大なご協力をいただき、実現することができました。詳しくは、以下のリンクをご参照ください。 www.sts-inc.co.jp 完了後の評価 4年間にわたる自営のデータセンターからAWSへの移行プロジェクトを振り返り、その成果を評価してみたいと思います。 多くの課題や困難に直面しましたが、関係者の皆様やパートナー企業、AWS担当者の皆様の協力のおかげで、プロジェクトは無事に完了しました。 コスト面での成果 私たちの移行プロジェクトでは、80％以上のインフラコストを変動費化することができました。これにより、必要な時に必要なリソースを柔軟に利用できる環境が整い、コスト効率が大幅に向上しました。 デリバリ効率の向上 AWSへの移行により、必要なリソースは即時に利用開始が可能となりました。これによって、デリバリまでのスピードが劇的に向上し、迅速なビジネスニーズへの対応が可能になりました。 品質と生産性の向上 移行後のシステムは耐障害性が格段に向上しました。しかし、今回は主にリフト＆シフト戦略を採用したため、定型作業の自動化はまだ道半ばにあります。さらなる自動化が今後の課題です。 エンジニアリングスキルの向上 移行を通じてクラウドノウハウを大いに蓄積できました。しかし、クラウドネイティブなエンジニアリングへの完全なシフトや、最新クラウド技術をビジネスの中に取り入れることは一部に留まっています。ここも今後の成長エリアとして捉え、継続的なスキルアップを目指しています。 一部サービスの再設計の効果 基本的にはリフト＆シフトで進めた移行でしたが、中には大胆にリファクタリングを行い、AWSのマネージドサービスを活用してクラウドネイティブなアーキテクチャに生まれ変わったシステムもありました。クラウドネイティブ化に成功したシステムでは、以下のような具体的な成果も得ることができました。 リリース工期の30％短縮 : リソース展開の迅速さが、全体のプロジェクト期間を短縮することに寄与しました。 投資コストの27％削減 : より効率的なシステム設計によるコスト削減が実現しました。 運用工数の削減 : サーバやリソースの増強、データベースのバージョンアップ作業が自動化され、運用負担が軽減されました。 これらの成果を糧に、今後はさらにクラウドの利点を最大限に活かせるよう、進化し続けていきたいと思います。 移行が成功した要因 次に、今回AWS移行が成功した要因を挙げたいと思います。 このプロジェクトには様々な挑戦がありましたが、無事に成功を収めることができた要因は、大きく分けて以下の3つです。 1. トップダウンのAWS移行判断 プロジェクトの初期段階では、基幹データベースのような一部のシステムは移行が難しいと考えていました。しかし、自営のデータセンターとAWSにデータを分散させることでコストが増大する試算となり、高難度の移行に踏み切ることになりました。ここで、経営層は移行のリスクを承諾し、全社を挙げての取り組みを促進してくれました。結果として、AWS移行にモチベーションを持てなかったシステム担当者の動機付けにもつながりました。 2. 移行をリードする能動的社員の存在 プロジェクトの推進には、進んで挑戦する能動的なシステム担当者の存在が欠かせませんでした。彼らは常に先陣を切ってトライし、発生した課題を迅速に見つけ出し、その解決策を他のシステム担当者に共有してくれました。これにより、後に続くシステム担当者にとっては多くの障壁が取り除かれ、スムーズに移行を進めることができました。 3. CoEによる技術支援 技術面での不安を抱えるシステム担当者も少なくありませんでしたが、CoEの存在が非常に大きな助けとなりました。移行に向けた基盤をしっかりと整備してくれることで、システム担当者は困難な状況でも「何とかなる」という安心感を持つことができました。その結果、技術的な障壁を乗り越え、移行を進めることができたのです。 これらの要因が揃い、AWS移行プロジェクトを成功に導くことができました。組織の一体感や前を行くリーダーシップ、そして確かな技術支援がプロジェクトの鍵を握ることを改めて実感しています。 最後に 昨年、何度か「AWS移行をしてよかったですか？」と尋ねられることがありました。 移行前に私たちが期待していた効果はほぼすべて実現できたため、私は自信を持って「はい、よかったです」と答えることができました。 しかし、それは私個人の視点での話です。他の社員はどのように感じているのか、気になったのでアンケートを取ってみました。 アンケートから得られた意見をいくつかご紹介します。全体的に、ポジティブな意見が多く、私たちBIGLOBEにおけるAWS移行は成功だと評価しています。 ポジティブな意見 コストが削減できた インフラが簡単に操作できる マネージドサービスを組み合わせると、開発や運用が非常に楽になった ネガティブな意見 コストを安くするために必要なサーバ管理（起動、停止）が手間 知識がないとインフラ操作が難しく感じる コンポーネントが多すぎて、トラブルシューティングが大変 もちろん、全てが完璧というわけではありませんでしたが、AWS移行のメリットを享受することができました。今後はさらにクラウドネイティブなアーキテクチャへのシフトを推進し、改善を続けたいと考えています。このシフトの成果が出た際には、ぜひまたブログでその内容を共有させていただきます。 追伸：AWS移行から本ブログ執筆までの1年間、私たちはAWS利用料金の削減に取り組んでいました。当初のAWS利用料金試算時の為替レートは1USD=114円でしたが、現在155円と円安が進んでしまっており、移行時のAWS利用料金が当初の試算と比較すると大幅に悪化していたためです。削減活動の結果、約20％のコスト削減を達成しました。これもまた一つの成功例として、いつかご紹介できればと思っています。

みなさん初めまして！新入社員のネットワーク技術部 牧添です。 2024年12月に沖縄で開催されたOkinawa Open Days 2024で会場ネットワーク構築プログラムに参加してきました。プログラムで取り組んだ内容や学んだことについてお伝えします。 Okinawa Open Daysとは 会場ネットワーク構築プログラムについて 事前準備 打ち合わせ ホットステージ 前日構築 OOD本番 終了後 感想 おまけ Okinawa Open Daysとは Okinawa Open Days (以下OOD)とは、Okinawa Open Lab (以下OOL)が主催するイベントで、 技術開発とビジネス、利用者と提供・運用者、エンジニアと学生など、それぞれの側面を持った参加者が集まり、技術と産業、社会のあるべき姿、デジタル社会の新たな可能性について議論し、交流する場 となっています。OOLのプロジェクトにはBIGLOBEからも参加しています。 詳しくは こちらの記事 をご覧ください。 今回のOOD2024は12月4日(水)〜12月6日(金)の3日間かけて開催されました。 総参加人数は数年ぶりに1000人を超えていたとのことでした！ 会場ネットワーク構築プログラムについて OODにおいて、会場ネットワークの構築や学生・若手インフラエンジニアのコミュニティー形成を目的とした「会場ネットワーク構築プログラム」というものがあり、今回私はこちらのプロジェクトに参加してきました。 昨年は同じネットワーク技術部の先輩が参加されており、「知識がつくし人脈もできるよ」と紹介してくださいました。 プログラムの内容として、具体的には以下のようなことを行ってきました。 対象業務 事前作業：会場内のネットワーク構築 インターネット到達性の提供 各講演のYouTube配信にて利用するためのネットワーク構築 ブース内の展示物にてインターネット利用するためのネットワーク構築 ケーブリング・ラッキングなどの物理作業 チャレンジ要素 会場Wi-Fi IoT(Internet of Things)機材を使った来場者数カウントシステムの構築 当日の運営 ネットワーク状態の監視 トラブルシューティング 事前準備 打ち合わせ 会場ネットワーク構築プログラムのキックオフは9月下旬に行われました。 私の他には、NTTコミュニケーションズ、さくらインターネット、国際電子ビジネス専門学校から参加されていました。主に若手社員と学生で構成されており、特に私含め1年目の新入社員の方が多かったです。 打ち合わせは週1回実施され、サーバーチームとネットワークチームに分かれ事前作業を進めたり、機器の選定などを行っていました。 私はネットワークチームとして参加することになりました。 ホットステージ ホットステージとは… 会場を模した環境で、 所定の機材でネットワークを組んでみて想定する動作をするか確認する （出典：JPNICブログ　 https://blog.nic.ad.jp/2016/997/ ） だそうです。私は初めて聞いた単語だったのですが、イベントの会場ネットワーク構築ではお馴染みのようです。 ホットステージは11月中旬から下旬で4日間(当初の予定では2日間)かけて行われました。 私は業務の都合で一部しか参加できませんでした… 場所はさくらインターネットの東京支社で行われました。 私はJuniper EX4300というスイッチの設定を担当しました。 複数のスイッチを論理的に一つのスイッチのように管理できるバーチャルシャーシを組んだり、インターフェース・VLAN(Virtual Local Area Network)・OSPF(Open Shortest Path First)などの設定を行いました。 2台ずつでバーチャルシャーシを構成しています 前日構築 OOD開催の前日、会場の沖縄市町村自治会館に集合しネットワーク構築作業を行いました。 まず事前に配送していた機器などを開封していたのですが、3ピン式の電源タップがなかったり、ラックのネジがなかったりと、慌ただしく準備を進めました。 ラックのネジは後で見つかったのですが、その頃には机上で機器をセッティングしてしまっており、最後までラックに移動されることはありませんでした… ラックが完成する前にセッティングされてしまった機器たち 最後までほとんど空だったラック 主に行っていた作業はLANケーブルの作成、接続でした。必要なLANケーブルの数と長さを計測した後は、8本の銅線を順番通りに並べ替えプラグに挿入し圧着する、という一連の流れをひたすら繰り返していました。本数が多かったため、機器に接続しLANケーブルを固定するのも苦労しました。 詳しいLANケーブルの作成方法はこちらをご覧ください。： LANケーブルを自作する方法 今回はガイド（ロードバー）があったので少し難易度は低くなっていました。 練習で作ったLANケーブル 大量生産されたLANケーブル 会場に置かれたスイッチ 前日構築では「最低限のサービスを提供する」ことを目標としており、事前に設計した構築通りにいかない部分もいくつかありました。あくまでも自分たちが実現したい構成や使いたい技術ではなく、ユーザーがサービスを問題なく利用できることが最優先ということで、サービスを提供するうえで重要な考え方を学ぶことができました。 OOD本番 本番中はネットワークの監視やトラブルが起きた際の対応がメインの業務でした。期間中は無事途切れることなくインターネットを提供することができました。 講演の様子 一方で、事前に設計した構成に変更するためにかなり試行錯誤していました。具体的には、さくらのクラウド上に構築したDNS・DHCPサーバをVPN越しに利用することを目指していました。 接続が上手くいかない原因に、BGP(Border Gateway Protocol)やOSPFといった普段の業務で馴染みのあるプロトコルの設定がありましたが、トラブル解決にほとんど貢献できず、自分の知識・経験不足を実感しました。 NOC(Network Operations Center)部屋 期間中は参加者の方やプログラムのメンバーとの交流も深めることができました。 BIGLOBEが参加している MDDOプロジェクト の打ち上げに誘っていただいたり、OOD参加者が集まるawabarに行ったり、OOD運営事務局であるOOLの打ち上げに参加したりと、様々な方とお話しすることができました。特にプロジェクトメンバーの方たちとは、入社1年目ならではの悩み(?)や普段の業務内容・仕事の進め方など、他社との違いを知ることができる貴重な機会となりました。 awabar OOL打ち上げ 終了後 OOD終了後は即撤収作業が始まり、ケーブルや機器を回収したり梱包したりと、慌ただしく動いていました。 梱包されているはずの部材が余っており、梱包して積んであった段ボールを全て開けて確認するというトラブルもありました。 後日、反省会＆お疲れ様会が実施され、良かった点や改善点について話し合いました。特に情報共有の部分に課題があり、各チームが具体的に何ができていて何ができていないかを互いに把握することができていませんでした。単に「〇〇ができた」というだけでなく、どんな項目を確認して判断したのかなど、報告の精度に改善が必要であるという結論に至りました。報告の精度については普段の業務でも意識していきたいと感じました。 感想 プログラムを通じて、スイッチの設定やLANケーブルの作成など、今まで触れたことがなかったものに触れることができ、貴重な経験になりました。また、他社の若手エンジニアや学生と協力して作業を進めたり、交流を深めることができる機会になりました。一方で、トラブルシューティングの際は何も貢献することができず、起きた事象の解説を聞くだけになってしまっていたので、今後同様のプログラムに参加する際は自ら問題を発見し解決に貢献できるよう力を付けたいと感じました。 おまけ 食事も楽しんできました！ 沖縄そばとハブ酒

開発部門（プロダクト技術本部）の高玉です。 BIGLOBEではオフィス生産性ツールにGoogle Workspaceを採用していて、普段のコミュニケーションはGoogle Chatを活用しています。また、Apps Scriptを使った業務効率化も盛んです。 Apps Scriptから生成AIを呼び出せるようになったことで、さらに業務を楽しく効率的にできるのでは？と考え、2024年9月に社内で「Apps Script x AI」と題した勉強会を開催しました。 社内で開催したAI x Apps Script勉強会 この記事では、勉強会向けに作ったハンズオンを紹介します。プログラミング初心者の方が、安心して作業できるように作ったハンズオンです。ぜひ一緒にアプリ開発を楽しみましょう！ Google Chatアプリ「ていねいちゃん」作成ハンズオン ステップ1: Google Cloudコンソールの準備 OAuth同意画面を設定する ステップ2: Apps Script スクリプトエディターでコードを書く ステップ3: Google Chat API の設定 公開設定する ステップ4: 動作確認 ステップ5: Geminiでテキストを生成する Gemini APIを有効にしてAPIキーを作成する スクリプトプロパティにAPIキーを保存する コードを追加する ステップ6: 敬語変換機能を追加 まとめ ご参考: GeminiのGemで作るには？ Google Chatアプリ「ていねいちゃん」作成ハンズオン こんにちは！今日は、Google Chatアプリ「ていねいちゃん」を一緒に作ってみましょう。ていねいちゃんは、カジュアルな言葉を丁寧な敬語に変換してくれるアプリです。変換には生成AIのGemini APIを利用しています。 ていねいちゃんとの会話 このハンズオンは、プログラミング初心者でGoogle Workspaceに興味がある方、そして生成AIのAPI利用に興味があり簡単なアプリ開発を体験したい方を対象としています。 実は、同じ機能であれば Gem （Geminiのカスタマイズバージョン）でも実現できますが、このハンズオンでは、よりカスタマイズ性が高く、他のGoogle Workspaceサービスとの連携も容易なApps Scriptを使って構築する方法を学びます。初めての方でも迷わないように、詳しく手順を説明します。安心して進めてください！ ステップ1: Google Cloudコンソールの準備 まず、Google Cloudコンソール でアプリに必要なAPIを有効にします。 Google Cloud コンソールの新規プロジェクト作成画面 にアクセスし、Googleアカウントでログインします。 プロジェクト名に「teinei-chan」と入力し、[作成] ボタンをクリックします（別のプロジェクト名でも大丈夫です）。 プロジェクトが作成されるまで待ちます。作成されると通知アイコンでプロジェクトを選択できます。プロジェクトを選択したら、プロジェクト番号をクリップボードにコピーします。 左上のナビゲーションメニューから「APIとサービス」→ 「有効なAPIとサービス」を選択します。 「＋ APIとサービスを有効にする」を押して、「Google Chat API」を検索し [有効にする] ボタンをクリックします。 APIとサービスを有効にする OAuth同意画面を設定する 次に、アプリが利用者にアクセス権を求めるときに表示される同意画面を作成します。 「APIとサービス」の左側のメニューから「OAuth同意画面」を選択します。 「内部」を選択して、[作成] ボタンを押します（社内に限定して公開するためです。後から変更する場合は公開設定を変更する必要があり、場合によってはGoogleの審査が必要になる可能性がありますのでご注意ください）。 アプリ名は「ていねいちゃん」、ユーザーサポートメールとデベロッパーの連絡先情報にはそれぞれ自分のメールアドレスを入力します。 スクロールして「保存して次へ」をクリックします（他のフィールドは空欄でOKです）。 ステップ2: Apps Script スクリプトエディターでコードを書く 次に、Google Apps Scriptで実際のアプリの動作を作成します。 https://script.google.com/home/start?hl=ja にアクセスして、画面一番下にあるチャットアプリをクリックして新しいプロジェクトを作成してください。プロジェクト名は「TeineiChan」とします。 チャットアプリ スクリプトエディターが表示されたら、左メニューから「プロジェクトの設定」を選びます。 Google Cloud Platform（GCP）プロジェクトの下にある [プロジェクトを変更] ボタンを押し、Google Cloudプロジェクト番号（先ほど作成したプロジェクトの番号）を入力します。これは、Apps ScriptプロジェクトとGoogle Cloudプロジェクトを紐付けることで、Apps ScriptからGoogle Cloudのサービス（Google Chat API、Gemini APIなど）を利用できるようにするためです。 プロジェクト番号を設定 次に、スクリプトエディターの「デプロイ」→「デプロイをテスト」をクリックし、ヘッドデプロイIDをメモします。このIDは、Google Chat APIの設定で、どのApps Scriptを実行するかを指定するために使用します。 ステップ3: Google Chat API の設定 Google Cloudコンソールで、Google Chat APIを設定します。 Google Cloud コンソールに戻り、Google Chat APIを検索して [管理] ボタンを押します。 「構成」タブで、以下の情報を入力します。 アプリ名: 「ていねいちゃん」 アバターURL: https://developers.google.com/chat/images/quickstart-app-avatar.png アプリの説明: 「敬語に変換します。」 インタラクティブ機能は「1:1のメッセージを受信する」をチェックして、ダイレクトメッセージで使えるようにします（Chatアプリを複数人で使う場合には「スペースとグループの会話に参加する」をチェックしますが、今回は使いません）。 接続設定に進み、「Apps Scrip」を選択し、先ほど取得したヘッドデプロイIDを入力します。 公開設定する Google Chat APIの「構成」タブの一番下にある「公開設定」で、「このチャットアプリを一部のユーザーに公開する」を選択し、自分のGoogleアカウントを追加します（これにより、アプリを自分でテストできるようになります）。[保存] ボタンを押します。 これでGoogle Chat APIの設定は完了です！ ステップ4: 動作確認 Google Chatで「ていねいちゃん」と会話してみましょう。 Google Chatを開き、左上にある「チャットの新規作成」を押して「ていねいちゃん」を検索し、チャットを開始しましょう。 メッセージを送信すると、最初はオウム返しでメッセージが返ってくることを確認してください。 ステップ5: Geminiでテキストを生成する 次に、メッセージを敬語に変換するコードを追加します。 Gemini APIを有効にしてAPIキーを作成する まず、Gemini APIを利用するのに必要なAPIキーを作成します。このAPIキーを知っている人は誰でもこのAPIを使えるようになります。絶対に公開しないでください。 Google Cloudコンソールに戻り、左上のナビゲーションメニューから「APIとサービス」→ 「有効なAPIとサービス」を選択します。 「＋ APIとサービスを有効にする」を押して、「Gemini API」を検索し [有効にする] ボタンをクリックします。 「APIとサービス」の左側のメニューから「認証情報」を選択します。 「＋認証情報を作成」を押して「APIキー」を選択します。 作成されたAPIキーをクリップボードにコピーします。 認証情報を作成 スクリプトプロパティにAPIキーを保存する APIキーはできるだけ秘匿したいです。スクリプトに直接記述すると、スクリプトの参照権限を持っている人に丸見えになってしまいます。スクリプトプロパティを使うことで、編集権限を持っている人にのみ見えるようにします。 スクリプトエディターに戻り、左側のメニューから「プロジェクトの設定」を選びます。 下にスクロールして [スクリプト プロパティを追加] ボタンを押して、新しいプロパティを入力できるようにします。 プロパティに「API_KEY」と入力し、値にコピーしたAPIキーをペーストします。 最後に [スクリプト プロパティを保存] ボタンを押します。 スクリプトプロパティを保存 コードを追加する 左メニュー「エディタ」を選択し、コード.gsに次のコードを追加します。 function generateText_(text) { const apiKey = PropertiesService.getScriptProperties().getProperty('API_KEY'); if (!apiKey) throw Error(`API_KEY がスクリプトプロパティに保存されていません。`); const url = 'https://generativelanguage.googleapis.com/v1beta/models/gemini-1.5-flash:generateContent?key=' + apiKey; const data = { contents: [{ parts: [{ text }] }] }; const response = UrlFetchApp.fetch(url, { method: 'POST', contentType: 'application/json', payload: JSON.stringify(data), muteHttpExceptions: true, }); if (response.getResponseCode() !== 200) { throw new Error(response.getContentText()); } const json = JSON.parse(response.getContentText()); return json.candidates[0].content.parts[0].text; } function testGenerateText() { const input = 'BIGLOBEについて教えて'; const output = generateText_(input); console.log(output); } コードを保存すると、エディタ上部の「実行する関数」に「testGenerateText」が表示されます。「実行」を押すと、Apps Scriptが使用する権限の確認プロセスがはじまります。権限を許可すると、実行ログに結果が表示されます。 保存した関数を実行 もし Generative Language API has not been used in project <あなたのプロジェクト番号> before or it is disabled. と表示される場合、Gemini APIが有効になっていません。手順を見直して、有効にしてください。 ちなみにApps Scriptでは、generateText＿のように、関数名の最後にアンダースコアをつけると、プラベート関数として扱われます。プライベート関数はエディタから直接実行できません（実行する関数、に表示されません）。関数が増えても、どの関数を実行すればいいんだっけ？と迷わなくなるので、ぜひ活用してください。 ステップ6: 敬語変換機能を追加 いよいよ丁寧な言い回しに変換する機能を追加します。 左メニュー「エディタ」を選択し、コード.gsに次のコードを追加します。 function makePolite_(message) { const prompt = `次のカジュアルな表現を、ビジネスシーンで使える丁寧な敬語に変換してください。二重敬語は禁止です。できるだけ簡潔に、敬意を込めた言い回しを使ってください。JTF日本語標準ガイドに従ってください。 ${message}`; return generateText_(prompt); } また、onMessage 関数はすべて削除して、次の新しい onMessage 関数に置き換えます。以前のonMessageはオウム返しをしていましたが、新しい関数では、Gemini APIを利用して受信したテキストを丁寧に言い換えます。 function onMessage(event) { return { text: makePolite_(event.message.text) }; } スクリプトを保存したら、Google Chatで「ていねいちゃん」に話しかけてみましょう！カジュアルなメッセージを送信すると、丁寧な敬語に変換されて返ってきます。 ていねいちゃんとの会話 ただし、生成AIは完璧ではありません。文脈によっては不自然な表現になる可能性があることを、予めご了承ください。 なお、プロンプトに「JTF日本語標準ガイドに従ってください」という指示を追加しました。スタイルガイドはこちらで公開されています。 www.jtf.jp 例えば、このガイドラインでは句読点や言い回しなどについて細かなルールが定められており、プロンプトでこの指示を与えることで、より自然で読みやすい敬語表現が生成されるようになります。 まとめ これでGoogle Chatアプリ「ていねいちゃん」の作成が完了しました！カジュアルな表現を丁寧な敬語に変換する便利なアプリです。 Gemでも同様の機能は実現できますが、Apps Scriptを使うことで、今回作成した敬語変換機能だけでなく、Google Workspaceの他のサービスと連携した新しい機能を作ることができます。 例えば、よくある質問（FAQ）をスプレッドシートで管理して、問い合わせに対応するAIボットを作ることができます。また、タスクをスプレッドシートで管理しているチームなら、タスクの進捗状況を確認できるAIボットができるでしょう。 引き続き、自分なりのカスタマイズを楽しんでください！ ご参考: GeminiのGemで作るには？ Gemを使えば、Apps Scriptのコードを書くことなく、丁寧な言い回しに変換する機能を手軽に実現できます。ただし、Apps Scriptで実現していた細かいカスタマイズや他のGoogle Workspaceサービスとの連携は難しくなります。 Gemで作ったていねいちゃん

ネットワーク技術を駆使し、次世代の通信インフラを支えるBIGLOBE。2024年夏、その若手社員たちが主導し就活生向け「ネットワークエンジニア業務体験」を開催しました。学生にリアルな業務体験を提供し、ネットワーク技術の魅力を伝えることを目的にしたもので、学生からも社内からも高い評価を受けています。 この記事では、 若手社員がゼロから作り上げたこのプロジェクトの裏側、そして挑戦を通じた成長の軌跡 を紹介します。 大田原和輝（おおたはら かずき） プロダクト技術本部　ネットワーク技術部　開発グループ 2023年4月新卒入社 冨尾理咲子（とみお りさこ） コーポレート本部　人事部　採用・活躍支援グループ 2023年4月新卒入社 人事とネットワークエンジニア、二人がBIGLOBEを選んだ理由 ゼロイチで企画し、提案。実現するまでの苦難の道のり 1年かけて準備した本番直前、まさかの事態とは 挑戦し、成長したい学生のみなさんへ 人事とネットワークエンジニア、二人がBIGLOBEを選んだ理由   —— 学生時代の就職活動や、BIGLOBEに入社を決めた理由を教えてください。   冨尾 ：大学では法学部で労働法を専攻しており、成果主義や労働者の健康確保に関する法制度について学んでいました。就職活動では、将来性が高い通信業界を中心に企業訪問をしており、その中の一つがBIGLOBEでした。 入社の決め手となったのは、「組織の歯車にならず、若手から裁量を持って働けること」。そして、「（女性としての）働きやすい環境や制度が整っており、長く働く姿が想像できたこと」や「業務体験プログラムや説明会で接した社員や面接官の人柄が良かったこと」などです。 大田原 ：僕は大学院でネットワークを学んでいました。就活の軸はISP事業を行っている企業で、いろいろ検討した中で、最終的にBIGLOBEに決めました。 決め手となったのは、面接で「こういうことやりたいです」と話した際に、「ぜひやってください」と前向きな返事をいただいたことです。また、組織の規模は大企業ほどではないにも関わらず、素晴らしい技術を持っていることも魅力的でした。実は、BIGLOBEのことをほとんど知らなかったのですが、面接を通してやりたいことをやらせてくれる企業だという印象を抱き、ここで働いてみたいという気持ちになりました。 —— 二人は2023年新卒で入社してから今まで、どのような業務を経験しましたか？（2024年12月インタビュー時）   冨尾 ：私は人事部で採用業務を担当しています。学生時代には労働法を専攻していたため、人事系の仕事に対しては興味がありました。正直なところ、最初は営業などの現場経験を積んでから、いずれ人事業務に携わりたいと考えていましたが、初年度から人事に関わる機会を得ることができました。そして、2年目からは新卒採用業務をほぼ一人で担当することになり、イベントの企画・運営、面接案内、内定者フォローなど、幅広い業務に携わっています。   大田原 ：入社してからプロダクト技術本部に所属し、主にDNSやマンションISPの回線運用を担当しています。一人ひとりが業務に大きな権限を与えられているため、課題に向き合う日々に飽きることがなく、大変なこともありますが刺激をもらえる仕事です。BIGLOBEはいろいろ挑戦できる環境がある、という入社前からの印象は間違っていませんでした。   ゼロイチで企画し、提案。実現するまでの苦難の道のり   —— 今回、「ネットワークエンジニア業務体験」を新たに立ち上げました。そのきっかけは何ですか？   大田原 ：最初のきっかけは、ちょっとした雑談からでした。あるイベントの打ち上げで、   南部長（現在は執行役員） に「BIGLOBEはインターネットを提供する会社なのに、なぜネットワークエンジニア向けの業務体験プログラムをやらないんですか？」と聞いてみたんです。食事の席での軽い話題でしたが、南部長はその場でスマホにメモを取り、「上の方にも話しておくよ」と言ってくれました。それが、このプロジェクトの始まりです。 その後、まずは「何をやるのか」という内容の合意が必要だったので、簡単な企画書を作ることになりました。その際に、同期入社の冨尾さんにも協力してもらい、人事部とネットワーク技術部で調整を進めました。   冨尾 ：大田原くんに最初に声をかけてもらった際は、会社としてもまだ「やります」と決定する段階ではなくて、情報収集が中心でした。そのため、すでに開催していたAWSオンラインプログラムの進め方や、プログラム参加者の本選考への移行率などの具体的なデータも含めて「何人の学生に来てもらう必要があるのか」といった話もしました。   —— きっかけは飲み会の雑談から始まり、同期と一緒にプロジェクト化へ進めたのは素敵ですね。   大田原 ：そうですね。僕自身、学生時代に参加したインターンシップがとても面白かったので、それをベースにしたものをBIGLOBEでもやりたいという思いが以前からありました。学生時代は使えるお金が限られていたため、高価なネットワーク機器に自由に触れる機会は貴重だったことや、参加するための交通費も出たことなど、そういうリアルな企業体験がとても楽しかったので、BIGLOBE版にアレンジして企画を考えました。   冨尾 ：他にも、学生が実際に社員と接することで、ありのままのBIGLOBEを理解して興味をもってもらうことや、ISP事業者の業務内容を理解できて「面白い！」と思ってもらうことをプログラム全体の目的としました。 —— 当時、二人とも入社1年目で、普段の業務もたくさんあった中でどのように進めたのでしょうか。   冨尾 ：もちろん目の前の業務もありましたし、プラスアルファで動く必要があったので最初は少し大変だなと感じました。でも、新しい取り組みを同期入社のチームで形にするのはやりがいがありましたし、先輩たちとも連携して進める中で学びも多かったですね。 あと、エンジニアの採用については、既存のAWSオンラインプログラムだけに頼らず、採用のもう一つの新しい軸としてネットワークエンジニアのプログラムを作るという挑戦は、企業の魅力を伝える上でもとても大事だと思いました。   大田原 ：そうですね。普段の業務とのバランスを考えながら、どのように形にするかをしっかり相談して進めました。僕の場合、とにかく自分が楽しいと思えることを全部盛り込みたいという思いが強かったので、いろいろと調整に苦労しました（笑）。学生にネットワークのことをもっと知ってほしいという思いと、採用につなげるというバランスで、普段の業務とはまた違った調整の難しさを味わえたのは、良い経験でしたね。   冨尾 ：企画が通るまでには何度も打ち合わせを重ねました。その過程で、お互いに「次回までにこれを調べる」「協力してくれそうな人を探す」などのタスクを分担しながら進めました。私自身、エンジニア向けのプログラム内容は正直わからないことも多かったのですが、大田原くんがとても楽しそうに話している姿を見て、「こういうワクワクした雰囲気なら学生さんも楽しんでくれるだろう」と想像しながら、一緒に取り組みました（笑）。その後、二人で目的や目標、具体的な実施タイミングやプログラムを検討し、上司に提案した流れです。   —— すべてが初めての経験だったと思いますが、企画を提案したときの上司の反応はいかがでしたか？   冨尾 ：好意的な反応で、「やってみよう」と背中を押してくれました。任せてくれることで、成果を出せるように頑張ろうという気持ちになれましたし、しっかり見守ってくれていることがチャレンジする上での安心感につながりました。   大田原 ：企画書については特に大きな修正はなく、いくつかアドバイスをもらいました。特に、学生向けに使用する資料についてはレビューをしてもらいました。その後、開催本番まで1年ほどあったので、その間に内容を詰めていくことがより重要でしたね。   冨尾 ：2人とも何もわからない状態だったので、AWSオンラインプログラムを立ち上げた方に協力してもらって定期的に話し合いをしたり、細やかにアドバイスをもらいながら進められたのも非常に助かりました。   大田原 ：僕自身は、困ったことばかりでした（笑）。1つ挙げると、当初思い描いていた「実際に機材を触って体験してもらう」という部分です。オフィスが入っているビルの制約で電源を落とすわけにはいかなかったり、場所の問題や音の問題があったりして、実現は難しいと感じました。そこで、「本当にこれが自分がやりたかったことなのか」と自分自身と向き合いながら先輩にも相談した結果、「今できる範囲で形にするのも良いし、将来的に実現できるようにステップを踏んでもいいんじゃないか」というアドバイスをいただき、納得して進めることができました。   —— 参加者の募集などはスムーズに進みましたか？   冨尾 ：はい。今年から就活ナビサイトでオプションを追加して、上位表示されるように工夫したことに加え、   JANOG というネットワーク好きな方が集まるイベントに参加して、学生と直接交流しました。 具体的には、そのJANOGのランチ会に参加し、学生に会社紹介やネットワークエンジニア業務体験の内容の説明をしたんです。そこで出会った学生さんの中からプログラムに参加してくれた方もいて、直接お会いして集客できたのは嬉しかったですね。 以上のような広報施策のおかげで集客については比較的スムーズに進めることができました。   大田原 ：その結果、定員を上回る応募があり、大きな反響がありました。   1年かけて準備した本番直前、まさかの事態とは 冨尾 ：そして、ついに迎えた本番直前。1年前から企画を始め、ついに開催の日を迎えられると思った矢先、台風が直撃して……。この予想外の事態に一時は焦りましたが、遠方から来る予定の参加者もおり、安全面を最優先に考え、早々に中止と延期の判断を下すことにしました。幸いなことに、上司や周りの方々がサポートしてくれたので、落ち着いて対応できました。   大田原 ：僕も「これは仕方ない」と割り切って、見学の調整を進めていたデータセンターにすぐに連絡を入れるなど、関係各所への対応に追われました。   冨尾 ：次回の日程を決める際には、学生のみなさんの夏休みスケジュールに合わせるためにアンケートを実施。その結果、9月末の祝日を利用して開催することになり、台風で中止となった回に予約していた方々を優先的に案内しました。今回は開催に向けて天気予報を頻繁にチェックしつつ（笑）、無事に開催できて本当に良かったです。   —— 実際に開催してみていかがでしたか？   大田原 ：まず、参加した学生のみなさんの優秀さに驚きましたね。基礎知識がすでにあることに加えてコミュニケーション力もあり、チーム作業でもすぐに打ち解け、互いに教え合う姿も見られました。ただ、参加者のレベルが想像以上に高くて、用意していた内容を早く終わらせてしまったんですよね。もっと内容を充実させても良かったかなという反省もあるので、次回以降に工夫したいです。   冨尾 ：参加学生のアンケート結果を振り返ると、データセンターの見学がとても好評でしたね。   大田原 ：そうですね。学生時代に自分自身がデータセンターを見学し感動した経験があるので、それを学生のみなさんにも共有できたことは本当に良かったです。リアルな現場を見学し、技術を肌で感じる体験は非常に価値があったと思います。   冨尾 ：座学だけではなく、実際に手を動かしてネットワークを構築できたことはエンジニア志望の学生のみなさんにとって有意義な体験となったようです。社員との懇親会の時間も設けていたので、ありのままのBIGLOBEを理解してもらうという目的は達成できました。   —— 実際に、このプログラムがきっかけとなり、エントリーや内定承諾に至った方もいらっしゃると伺いました。   冨尾 ：そうですね。26卒エンジニアの一次募集が始まっていますが、内定承諾の理由に「ネットワークエンジニア業務体験の経験」を挙げてくれる方がいました。これは成果を実感できるポイントでしたね。プログラムに参加することで、BIGLOBEで働きたい！と思っていただけたのがすごく嬉しかったです。 特に「社員の方が楽しそうにされていて、自分もBIGLOBEでなら楽しく働きながら成長できそうだと思った」とおっしゃっていただいたときは、プログラムを実施できて本当に良かったと感じました。   —— もしこのプログラムがなかったら、その方たちとBIGLOBEの接点が持てなかったかもしれないと考えると、きっかけを提供できたのは良かったですね。社内からも高い評価を得たと聞いています。   冨尾 ：人事部としては、新しい取り組みを入社2年目で実現できたことを評価していただきました。その成果が採用にも結びつき、選考に来ていただけた学生がいた点も含め、お褒めの言葉をいただいたのは嬉しかったです。 大田原 ： このプロジェクトは、プロダクト技術本部の重要施策として位置づけられました。プレッシャーを感じながらもプロジェクトメンバー全員で協力し、工夫を重ねながらやり遂げた結果、学生にネットワークへの興味を持ってもらい、採用承諾という成果にもつなげることができました。これらの功績が認められ、本部から「本部長賞」をいただきました。 ・ネットワークエンジニアの将来を想像することができました。 ・初めて本プログラムを開いたということでしたが、内容が素晴らしく、ネットワークって楽しいなと改めて思うことができましたし、ネットワーク業界にやっぱり就職したいなと思うことができました。 ・データセンターの役割や設備、さらにデータセンターからサービスを展開していBIGLOBEさんの話を聞けたことは、これからのネットワーク業界に就職する意欲につながりました。 ・お客さまのサービスを支えている装置を見て、会社の一員として働く自分を思い浮かべることができました。 参加学生からも高評価！アンケート結果を一部抜粋   一方で、厳しい指摘もいただきました。反省点としては、段取りの不足や予想以上に工数がかかったことなど、いくつかの課題が浮き彫りになりました。   冨尾 ：1年間かけて取り組んだプロジェクトですので、「次にどうすれば良いか」という道筋はすでに立てています。今後に向けて、継続的に改善していきたいですね。   —— このプロジェクトを通じて、自分自身が成長できた点やキャリアへの影響についてはどのように考えていますか。それぞれ教えてください。   大田原 ：一番成長を感じたのは、コミュニケーション能力とマネジメントスキルです。このプログラムは、全体のスケジュールや必要なリソースの洗い出し、そして多くの関係者と調整することが求められました。特に、さまざまな部署や協力社員の方々、さらに他社との連携が重要で、進捗状況の確認やタスクの割り振りなどを通じて、多くのことを学びました。   冨尾 ：私にとっては、新しいことへの挑戦のハードルが下がったのが一番の成長です。以前は新しいことに挑戦するのはあまり得意ではないと思っていたのですが、同期の大田原さんのチャレンジに刺激を受けたり、今回の成功体験を通じて、前向きに取り組めるようになりました。この経験は、今後のキャリアや新しい取り組みに活きると思います。 お互い初めてのことが多かったので、悩んだり気分が落ち込んだときは相談したりしていました。同期なので本音の部分も話しやすく、頼りがいもありました。   挑戦し、成長したい学生のみなさんへ —— 今回のプロジェクトを通じて、BIGLOBEのカルチャーについては、どのように感じましたか？   冨尾 ：私の就活の軸は「若手のうちから裁量を持って働けること」や「人間関係の良さ」でした。今回のプロジェクトを通じて、それを改めて実感できました。 BIGLOBEで働いていると常々感じていることですが、協力的で穏やかな方が多くいます。周囲の方に今回のプロジェクトについてアドバイスをいただいたり、困ったことはないかをこまめに気にしていただいたりしていたので、メンタルの面でも非常に助かりました。さらには、当日の学生対応についてはネットワーク技術部総動員で協力してくれたりもして。 新卒採用はたくさんの社員の方の協力があってこそ成り立つので、いつもみなさんへの感謝の気持ちでいっぱいです。   大田原 ：BIGLOBEの魅力は、若手でも挑戦の機会を与えられ、それを支える周りの協力がある点だと思います。社内のコミュニケーションが活発で、今回も多くの人のサポートを受けながら進めることができました。 上司が言っていたのが「スキルや経験よりも、やる気や前向きな姿勢が大事」という言葉。それに支えられて僕自身もチャレンジできました。特に、自分が楽しんで取り組めることに注力する姿勢を学びました。   —— 最後に、この記事を読んでいただいた学生さんにメッセージがあればお願いします。   冨尾 ：私自身、入社2年目ながら新しいイベントを企画してみたり、採用動画を作成してみたり、やってみたいことをやらせてもらえています。新しいことに挑戦したい学生のみなさん、ぜひ一緒にBIGLOBEで働きましょう。   大田原 ：冨尾さんと同じく、自分の興味を持ったことには素直に挑戦してほしいというメッセージを送りたいですね。どんなに小さなことでも、楽しんで取り組めば、新しい学びや成長につながります。通信ネットワーク業界やBIGLOBEの就活生向けイベントに興味を持っていただいた方は一緒に学び、成長していきましょう！   —— 本日はありがとうございました！   現在、BIGLOBEでは2026年卒向け新卒採用を行っています。 少しでもBIGLOBEに興味をもっていただけた方は、ぜひ下記URLよりマイページ登録をお願いいたします。 https://mypage.3010.i-webs.jp/biglobe2026/applicant/login/baitai-entry/entrycd/Style ※「初めての方はこちら」より、新規登録をしてください。   www.biglobe.co.jp  

BIGLOBEでは、様々なオンボーディング施策を実施しています。本記事では、先日開催された開発部門 中途社員同士の交流会について紹介します。 中途社員が新しい環境に馴染むことの難しさ 当日の様子 準備から始まる交流 自己紹介資料で交流を活性化 ゲストとの交流 AI活用による中途マッチング アンケート結果 今後の展望 おわりに こんにちは。開発部門（プロダクト技術本部）の山崎美恵です。 BIGLOBEの開発部門では、採用強化に伴い 2024年度に約30名の中途社員が入社しました。30名の中途社員がスムーズに会社に馴染み、活躍できるよう、さまざまなオンボーディング施策を実施しています。 その中でも特に好評なのが、 部門の垣根を超え 中途社員同士の交流を目的とした「中途交流会」 です。 今回の記事では、先日行われた「中途交流会」の様子をお伝えしたいと思います！ 中途社員が新しい環境に馴染むことの難しさ 中途社員は、新しい会社において文化、仕事の進め方、人間関係など、多くの異なる点に適応する必要があります。 特に、社内の人間関係は、仕事を進める上でも非常に重要です。 しかし、既存の社員ネットワークの中に溶け込むことは容易ではなく、孤独感や疎外感を感じてしまう中途社員も少なくありません。 このような課題を解決し、中途社員がスムーズに新しい環境に馴染むためには、社内コミュニケーションが非常に重要となります。 そこで、BIGLOBEの開発部門では、中途社員同士が交流できる場を提供し、不安や孤独の解消、社内ネットワークの構築を支援すべく「中途交流会」を定期的に実施しています。（今回が３回目の開催となります。） 当日の様子 準備から始まる交流 準備段階から既に交流は始まっています！ ！ 前回の交流会アンケートで「設営、片付けも皆で行えば、その時間も貴重なコミュニケーションになると思いました。」というご意見をいただき、今回はドリンクの買い出しを中途社員の数名にお願いしました。 買い出しという作業を通して、自然と会話が生まれ、和やかな雰囲気で交流会がスタート！！ 業務で接点のないメンバー同士が協力し準備する時間は、まさに貴重なコミュニケーションの時間となりました。参加者からも「買い出しや帰路でも交流ができて、充実した時間を過ごせました。」という嬉しい声が聞かれ、前回のアンケートでいただいたご意見を反映したことで、より良い交流会になったと感じています。 自己紹介資料で交流を活性化 交流会をより有意義な時間にするため、中途社員の皆には事前に自己紹介資料を作成いただきました。 この資料には、担当業務やスキルだけでなく、趣味や特技、興味関心など、皆の個性が出るような内容を盛り込んでもらっています。 作成いただいた自己紹介資料は、他の参加者にも共有し、資料を通して他の参加者について事前に知ることできます。事前に共有することで、交流会当日、共通の話題を見つけやすくなること、また、聞きたいことや話したいことを事前に整理できるため、参加者同士の円滑なコミュニケーションを促進する上で、大変効果的だったと考えています。 ゲストとの交流 中途交流会では、普段話す機会の少ない本部長、副本部長、人事部をゲストとしてお招きしました。 こういった交流会の場で、経営層や人事部との距離が縮まることで、中途社員は「会社の一員として認められている」と感じ、帰属意識やモチベーションが高まります。その結果、エンゲージメント向上に繋がり、組織全体への良い効果が現れるのではないでしょうか。 アンケートでも「普段交流する機会がないので良かった！」「次回もまた来てほしい！！」と大変好評でした。 AI活用による中途マッチング 今回は、中途社員同士の交流を更に深めるため、少し工夫を凝らしAIを活用した中途マッチング♡を企画しました。 前述の通り、参加者には、担当業務やスキルに加えて、出身地や趣味、興味関心など、個性あふれる内容を盛り込んだ自己紹介資料を作成してもらっています。そして、この自己紹介資料を GoogleのAI技術であるNotebookLMに学習させ、参加者同士の共通点や興味関心の一致度に基づいてマッチングを行ってもらいました。 NotebookLMでの中途マッチング結果 マッチングの結果、交流会当日は5組のカップルが誕生し、発表時は大変盛り上がりました！！ 交流会後のアンケートでは、AIマッチングに対して多くの好意的な意見が寄せられており、ある方は「ソースに同じ文言があるだけでマッチングしているだけかと思ったら、AIが独自で考えてマッチングさせていた箇所が見えて、面白かった」と、AIの分析能力の高さを評価しています。 その他、「ばっちりです！」「AIが活用されてて楽しかったです！」と、AIマッチング自体を楽しんでる方や、 「後半の会話のきっかけになってとてもよかったです！」「”〇〇の話題で気が合いそうです”という判定は、会話に繋がるので良いなと思いました。」という声もありました。 AIを活用したマッチングは、参加者同士の意外な共通点や興味関心を見つけ出し、会話のきっかけを提供する上で大変効果的だったと感じています。 アンケート結果 アンケート結果によると、参加者の満足度は非常に高く、ほとんどの方が交流会に好意的でした！ また、自己紹介資料を活用したAIマッチングは、概ね好評で、参加者同士の会話のきっかけ作りに貢献したと考えられます。 今後の展望 これまでの中途交流会は、中途社員同士の懇親を深めることを主眼に開催してきましたが、アンケートで「既存社員との交流も深めたい」という声が多く寄せられました。 中途社員が既存社員と交流することで、社内のコミュニケーションが円滑になり、業務上の連携がとりやすくなります。 また、既存社員も中途社員の新しい視点やスキルから刺激を受けることで、組織全体の活性化に繋がります。 今後の中途交流会では、中途社員同士だけでなく、既存社員も巻き込んだ交流の場にしていこうと考えています。 部門や立場を超えた交流を促進することで、より風通しの良い社風を目指すとともに、中途の方がよりスムーズに組織に溶け込めるよう引き続きサポートを強化していきます。 おわりに 3回目の開催となる中途交流会は、盛況の中、無事に終えることができました。多くの参加者から「すごくよかったです。」「次回も参加したい。」といった嬉しい声が多数寄せられました。 今回の交流会が、中途社員の皆にとって、BIGLOBEの一員としての意識を高め、より活き活きと活躍できるきっかけになれば幸いです。 今後も、中途社員の皆様が安心して業務に臨み、能力を最大限に発揮できるよう、様々な取り組みを継続してまいります。 そして、この交流会が、部門や立場を超えたコミュニケーションを促進し、より風通しの良い、一体感のある組織づくりの一助となることを願っています。 「中途交流会」概要 ・対象：2024年度 プロダクト技術本部 中途社員 ・ゲスト：プロダクト技術本部 本部長、副本部長、人事部など ・事前作業：各自 自己紹介資料を作成（出身・趣味・特技・経歴など） ・懇親会の流れ（約2時間）： 　懇親会 開始 　　-プロダクト技術本部 本部長より乾杯の挨拶 　　-アイスブレイク（AI中途マッチング） 　　-プロダクト技術本部 副本部長より終了の挨拶 　懇親会 終了 　　-皆で片付け ※ このブログは、Google によって承認または提携されているものではありません。

皆さん初めまして、プロダクト技術本部の加藤です。 BIGLOBEでは、社員のスキル向上と最新技術への理解を深めるために、定期的にAWS勉強会を実施しています！ 今回の勉強会用に、私は初めてCloudFormationを使用して環境構築を行いました。その際に、AIを活用してYAMLファイルを生成する方法を試してみました！このブログが、CloudFormationを活用する際に、少しでも役立てば嬉しいです。 AWS勉強会の概要 環境構築の手順 生成AI活用によるYAML作成の流れ 生成AI活用の利点・課題 生成AIのメリット 生成AIのデメリット おわりに AWS勉強会の概要 今回のAWS勉強会では、「Aurora MySQL パッチ適用ワークショップ」をテーマに、パッチ適用や切り戻し時の流れを学びます。実際のパッチ適用を体験してもらうため、本番環境に近しい環境を構築して参加者に提供することになりました。また、生成AIを使用することにしたのは、YAMLファイルの作成に不慣れであったためです。生成AIを活用して、ルールや必要な手順について教えてもらいながらファイルを作成することで、より効率的に作業を進められると考えました。 今回作成する環境の要件は以下となります。 VPCを作成。パブリックサブネット1つ、プライベートサブネット2つ パブリックサブネットにEC2を１台、プライベートサブネットにAurora MySQLをreaderとwriterで１台ずつ構築 EC2とAuroraにそれぞれSGを作成 EC2にはAuroraと通信が出来るように、AuroraもEC2と通信が出来るように設定 EC2からAuroraの操作を行うため、EC2にアタッチするロールを作成。必要なポリシーはAuroraの操作権限 Aurora MySQLのバージョンは3.05.2を指定して構築する 今回作成する環境の構成図 環境構築の手順 ハンズオン環境作成において以下のような流れで作成しました。 AIチャットツールによるYAMLテンプレートの生成 まず初めに、ハンズオン環境を迅速かつ効果的に構築するためにAIチャットツールを活用しました。生成AIによって生成されたテンプレートをベースとして、改善を繰り返すことでより適切な形に仕上げていきました。 CloudFormationスタックのデプロイ YAMLテンプレートの準備が整った後、AWSマネジメントコンソールでCloudFormationスタックのデプロイを実施しました。デプロイ中に発生したエラーを順次修正することで、コードの完成度を高めていきました。 Instance Connectでの接続確認 最後に、PoC環境内に構築したEC2インスタンスへInstance Connectを使って接続し、Auroraとの接続が正常に行われていることを確認しました。この手順を通じて、YAMLファイルにより構築された環境が期待通りに動作していることを確かめることができました！ 生成AI活用によるYAML作成の流れ それではAIと一緒にYAMLを作成した経緯を書いていきます！ 今回、私が選んだのはClaude-Sonnet(16K)というAIです。選定理由は、返答が明快でわかりやすく、聞いたことに対して適切に答えてくれる印象があり、今回のようなコード生成には適していると考えたからです。また、画像認識の精度が高く、構成図を用いて指示を出す際にも役立つと見込んだ点も大きなポイントでした。 最初の指示文はこのようにしていました。なお初期の段階では要件が少し違います。 加藤 ： AWSのAurora MySQLのバッチあてを行うワークショップを開きます。 そのためのYAMLファイルを作りたいです。 大まかな構成図は画像の通りで 大まかな要件は下記です。 VPCは(10.0.0.0/16)を利用 プライベートサブネットを作成 プライベートサブネットにEC2を１台、Aurora MySQLをreaderとwriterで１台ずつ構築 EC2とAuroraにそれぞれSGを作成 EC2にはAuroraと通信が出来るように、AuroraもEC2と通信が出来るように設定 EC2からAuroraの操作を行うため、EC2にアタッチするロールを作成。必要なポリシーはAuroraの操作 権限 Aurora MySQLのバージョンは「MySQL 3.05.2」を指定して構築する リージョンは東京 他はデフォルト設定(コスト効率を意識して) この要件でYAMLを作成してください。 生成AI ： 東京リージョン（ap-northeast-1）でのデフォルト設定を使用して、簡単なYAMLファイルの構成例を以下に示します。この例はAWS CloudFormationを使ってリソースを構築するものです。 AWSTemplateFormatVersion : '2010-09-09' Description : Aurora MySQLとEC2インスタンスの設定 Resources : MyVPC : Type : 'AWS::EC2::VPC' Properties : CidrBlock : '10.0.0.0/16' EnableDnsSupport : true EnableDnsHostnames : true MySubnet : Type : 'AWS::EC2::Subnet' Properties : VpcId : !Ref MyVPC CidrBlock : '10.0.1.0/24' AvailabilityZone : 'ap-northeast-1a' (中略) MyDBCluster : Type : 'AWS::RDS::DBCluster' Properties : Engine : aurora-mysql EngineMode : provisioned EngineVersion : '5.6.mysql_aurora.1.22.2' # MySQL3.05.2相当 DatabaseName : mydatabase DBSubnetGroupName : !Ref MyDBSubnetGroup MasterUsername : admin MasterUserPassword : !Sub '${AWS::StackName}-masterpass' VpcSecurityGroupIds : - !Ref MyAuroraSecurityGroup MyDBInstanceWriter : Type : 'AWS::RDS::DBInstance' Properties : DBClusterIdentifier : !Ref MyDBCluster Engine : aurora DBInstanceClass : db.r5.large PubliclyAccessible : false (以下略) 注意: KeyNameには、ご自身のSSHキーペア名を入力してください。 ImageIdには、対象のリージョンで利用可能なAMI IDを提供してください。Amazon LinuxなどのAMIを使用することが一般的です。 この例では、基本的にデフォルトまたは指定された設定に基づいてAWSリソースを作成しています。このテンプレートを実行する前に、適切なアクセス許可があることを確認してください。 これで基本的な要件を満たしたYAMLファイルを生成することができましたが、いくつか問題点がありました。 EC2はキーペアなしで生成してほしかった。 AuroraはReaderとWriter2台必要なので、サブネットは2つ生成する必要があるが、1つしか作成されていない Auroraのエンジンバージョンの指定の書き方が違う などです。 またこれらのエラーを解決する過程でさらに問題が浮上しました。 AMI IDがいつの間にか書き変わっている 生成しないパラメータをRef関数で利用していた 修正したコードを教えないと、元のコードに戻してしまう 指示をしているうちに混乱してきたので、最終的にYAMLファイルを1行ずつ説明してもらうことにしました。 加藤 ： 今できてるYAMLファイルの中身を1行ずつわかりやすく解説して。 生成AI ： では、YAMLファイルの主要な部分を1行ずつ、より具体的に解説していきます。 AWSTemplateFormatVersion : '2010-09-09' Description : Aurora MySQLとEC2インスタンスの設定（デフォルトVPC利用、Amazon Linux 2023） これは設計図の基本情報です。いつの形式を使っているか、何を作るかを説明しています。 Mappings : RegionMap : ap-northeast-1 : AMI : ami-03f584e50b2d32776 これは地域ごとに使うコンピューターの種類（AMI）を決めています。ここではap-northeast-1（東京リージョン）で使うAMIを指定しています。 Resources : PrivateSubnet : Type : 'AWS::EC2::Subnet' Properties : VpcId : Fn::ImportValue : !Sub '${AWS::Region}-VPC-ID' CidrBlock : '172.31.48.0/20' AvailabilityZone : !Select [ 0 , !GetAZs '' ] MapPublicIpOnLaunch : false ここでプライベートサブネット（隔離されたネットワーク空間）を作っています。VPCという大きなネットワークの中に作り、IPアドレスの範囲を指定しています。 MyEC2SecurityGroup : Type : 'AWS::EC2::SecurityGroup' Properties : GroupName : EC2SecurityGroup GroupDescription : Allow MySQL from VPC VpcId : Fn::ImportValue : !Sub '${AWS::Region}-VPC-ID' SecurityGroupIngress : - IpProtocol : tcp FromPort : 3306 ToPort : 3306 SourceSecurityGroupId : !Ref MyAuroraSecurityGroup EC2用のセキュリティグループ（ファイアウォール）を作っています。データベースからの接続（ポート3306）を許可しています。 MyDBSubnetGroup : Type : 'AWS::RDS::DBSubnetGroup' Properties : DBSubnetGroupDescription : Subnet group for Aurora SubnetIds : - !Ref PrivateSubnet - Fn::ImportValue : !Sub '${AWS::Region}-SubnetID1' データベース用のサブネットグループを作成しています。先ほど作ったプライベートサブネットと、別の場所から持ってきたサブネットを使います。 MyDBCluster : Type : 'AWS::RDS::DBCluster' Properties : Engine : aurora-mysql EngineVersion : '5.7.mysql_aurora.2.11.2' DatabaseName : mydatabase MasterUsername : admin MasterUserPassword : !Sub '${AWS::StackName}-masterpass' Aurora MySQLクラスター（データベースの集まり）を作成しています。データベース名やユーザー名、パスワードを設定しています。 MyEC2Instance : Type : 'AWS::EC2::Instance' Properties : InstanceType : t2.micro ImageId : !FindInMap [ RegionMap, !Ref "AWS::Region" , AMI ] SubnetId : !Ref PrivateSubnet SecurityGroupIds : - !Ref MyEC2SecurityGroup IamInstanceProfile : !Ref MyEC2InstanceProfile EC2インスタンス（仮想サーバー）を作成しています。サイズや使用するイメージ、配置するサブネット、セキュリティグループを指定しています。 これらの設定が組み合わさって、安全に使えるコンピューターとデータベースの環境が作られます。 コードの基本的な解説を受けて、そこでドキュメントを読み比較することで、エンジンバージョンの書き方が異なっていることや、必要なサブネットが複数あるのに記述が不足していることに気が付くことができました。また、理解を深めるために短縮された関数（例: !Ref）をすべて展開して表記するように依頼し、生成AIの誤りを見抜きながらYAMLの生成を進める方向にシフトしました。 最終的には、少し手直しを加え、自力でワークショップで使用するYAMLファイルを作成することができました！ 生成AI活用の利点・課題 AIチャットを使ってYAMLファイルを生成することで、その便利さとともに、課題も見えてきました。まだ使い切れていない部分もありますが、私が感じたメリットとデメリットを共有します。 生成AIのメリット はじめの一歩を踏み出しやすい 生成AIは専門知識がなくても、簡単なコードを生成したり、概念やルールを教えてくれます。初心者が専門分野への第一歩を踏み出す際にとても役立ちます。私自身、IaCによるAWSの環境構築を全くの未経験から始め、勉強会のハンズオン環境を作成することができました。生成AIは基本的な概念や作成手順をわかりやすく教えてくれ、全体としての進め方に迷うことはありませんでした。 デバッグに役立つ 長文やわかりにくいエラーメッセージから根本原因を見つけることは時間がかかる作業です。AIチャットにエラーメッセージを入力すると、エラーの原因を教えてくれるため、適度に活用することで、時間を大幅に短縮できると感じました。 話しているだけで楽しい 一人で作業していると気がめいってきますが、生成AIと一緒に会話しながら作業を進めることで、楽しく段階的に作業を進めることができました。作業中にちょっとしたコミュニケーションも楽しめるのが良かったです。 生成AIのデメリット 誤情報の生成リスク 生成AIは誤った情報をいかにも正しそうに生成することが度々あります。間違いを見つけて修正するためには、利用者が自分で理解を深める必要があります。今回はコード生成のみだったため、エラーの有無で嘘を見分けることができましたが、専門知識を利用して文章を利用するなどの場合においては嘘を見つけることは初心者には非常に難しいように思います。 要件を明確化する必要がある 人間同士では暗黙の了解で省略できる要件も、生成AIに指示する際には明確に伝える必要があります。要件を見落とすとエラーに遭遇したり、生成AIの判断で勝手に要件を書き換えてしまう場合がありました。今回の場合では、リージョンやAZの指定、インスタンスタイプの指定などにおいて、暗黙の了解がありました。 自分で調べるタイミングがある 生成AIが出したコードがうまく動作しない場合、エラーの原因をAIチャットで尋ねても誤解していることがあります。生成AIに頼りすぎると、一緒に迷走し、大きな時間を費やすことになり得ます。そこで、AIチャットに頼りきりにせず、自分で調べる時間を設けることが重要だと私は感じました。生成AIがミスを犯した際も、別の視点から自力で発見するための検証が必要です。 おわりに 今回のブログでは、AIチャットツールを用いてCloudFormationのYAMLファイルを生成し、AWS環境を構築する経験を共有しました。AIチャットツールは様々なプロジェクトの最初の一歩を踏み出すことに役立つと感じた一方、取り扱い上の課題や注意点についても知見を得ることができました。 今後は公式のドキュメントやサンプルコード等を事前に学習させた生成AIによるコード生成を試し、より精度の高い支援が受けられるようにしたいと考えています。 ここまでお読みいただきありがとうございました。 ※ Amazon、Amazon Web Services、AWS、各種AWSサービスは、Amazon.com, Inc.またはその関連会社の商標または登録商標です。 ※ Claude は、Anthropic, PBCの商標または登録商標です。 ※ 記載している企業、団体、製品、サービス等の名称は各社またはその関連会社の商標または登録商標です。

プロダクト技術本部の川口です。 今回は、新人エンジニア研修にモブプロを導入してワークしてもらったら予想以上に高い満足度を得られた話を紹介します。 まずは弊社の新人エンジニア研修について紹介します。 BIGLOBEでは2020年から新人エンジニアが対象のエンジニア研修を実施しています。 研修内容は、Unix/Linux、Git、ネットワーク演習などどこの企業さんでもやっているような内容です。 2022年までは、教育担当のエンジニアが一人でカリキュラムと研修の講師を担当していました。 去年からは、カリキュラムは従来通り教育担当のエンジニアが考えるものの、研修の講師は育成も兼ねて新卒2〜4年目の若手エンジニアが研修の内容を考えて講師を務めることになりました。 業務の内容から講師の担当を割り振るのですが、私が所属するチームでは内製で開発しており、普段からコーディングも行っているため、TDD研修の担当になりました。 これまでのTDD研修 自分が考えたTDD研修 研修をやる上で心がけたこと 新人の声 おわりに これまでのTDD研修 これまでのTDD研修では、TDD Boot Camp 2020のt-wadaさんのライブコーディングの動画を視聴し、動画を基にしたクイズを解いたり、個人で簡単なユニットテストにちなんだワークを行っていました。 私自身も新人のときにTDD研修を受けましたが、研修後に理解を深めたくて、自主的にTDDに沿ってテストを書いてみました。 この経験から一人でやるのではなく、新人が理解度を確認し合えるように、新人同士でTDDに沿ってテストを書いてみるワークをさせてみたほうがいいかもしれないと思いました。 自分が考えたTDD研修 まずは去年と同様に、t-wadaさんのライブコーディングの動画を視聴して、体系的な知識を得てもらうようにします。 動画を視聴した後にライブコーディングでもやっていたFizzBuzz問題のプロダクトコードとテストコードを新人同士でモブプロで動画と同じようにTDDで書いてみるワークを導入しました。 動画ではJava + JUnitでやっていましたが、環境構築が簡単なJavaScript + Jestでやることにしました。 FizzBuzz問題が終わったあとは、競技プログラミングの簡単なアルゴリズムの問題をTDDで書いてみるワークを導入することにしました。 研修をやる上で心がけたこと モブプロでは新人全員がドライバーとナビゲーターをローテーションしながら全員参加すること。 モブプロで手を動かす前に、次に何があるか、どういうタスクがあるかを全員に聞き、新人同士で確認し合いながらワークを進めることを心がけました。 新人育成の場でゴールを達成するために必要な仕事を細かなタスクに分解していくタスクばらしを行うことがあると思います。 TDDはプログラミングの世界のタスクばらしに近いものがあると考えているため、視聴した動画の内容を振り返りながら、タスクを確認し合ってワークをしてもらいました。 加えて、手を動かした後は「なぜそう考えたのか」を説明してもらうことにしました。 特に最後のアルゴリズムの問題は、FizzBuzz問題と違い、その場でプロダクトコードとテストコードを考える必要があります。 プロダクトコードの説明とどういったテストケースのパターンが必要か新人同士で議論しながらワークを進めてもらいました。 新人の声 研修では、最後にアンケートをとっています。 感想と満足度を聞いているのですが、新人の感想を1つ紹介します。 ＜新人＞ TDDの概要を聞くだけではわからなかったが、動画のデモ、モブプロを通してどういった手法なのかを学べた。 実践的なTDDのワークにモブプロを取り入れたことで、理解が深まったようでした。 研修の満足度は、新人が６名の中、9点が3人、10点が3人と高評価を得ることができました。 準備は大変でしたが、新人に満足してもらえたようでとても嬉しかったです。 おわりに 今回はTDD研修を行った際の紹介でしたが、他の研修の講師も担当していたり、同期のエンジニアが違う研修の講師を担当しています。 皆、研修の資料を作成したり、講師をやる中で理解が足りてなかったと気づくことが意外と多かったようです。 新人だけでなく、講師をする若手エンジニアにとっても学びになるのがよい相乗効果だと感じました。 これからも満足して、現場で実践できるような研修をつくりあげていきたいと思いました。

こんにちは。BIGLOBE Style編集部の冨尾です。 BIGLOBEでは、夏の開催に続き、12月にもAmazon Web Services（AWS）に触れることができるオンラインプログラムを開催します！ 本プログラムの特徴は、実際にAWSに触れてインフラの構築やトラブルシューティングなどの実務的な体験ができること。少人数のグループで若手社員と一緒に取り組むため、アドバイスを受けながら効果的に学んでいただけます。 インフラからアプリまで幅広い興味のある方や、クラウド（AWS）に興味はあるけれど使った経験がないといった方におすすめのプログラムですので、ぜひご参加ください。 AWSは個人で利用する場合に費用の面でハードルが高いと言われることもありますが、今回のプログラムでは費用は会社負担となりますので、そのハードルもゼロ！ 毎年、参加者のみなさまから大変ご好評をいただいているプログラムです。 この機会に、ぜひAWSの魅力を体験してみてください。 AWSオンラインプログラムの概要 内容 参加にあたって 日程 応募方法 AWSオンラインプログラムの魅力 おすすめポイント プログラムへ参加するとこんなことができるようになります 今年度サマープログラム参加者の声 ファシリテーターからひとこと AWSオンラインプログラムの 概要 内容 2日間を通してAWSの基礎と、システムに問題が発生した際の解決方法について学んでいただきます。 1日目はハンズオン形式でAWSの基礎を学んでいただき、基本的なWebシステムを構築します。 2日目は1日目で学習した知識を活かして、実践的なトラブルシューティング(問題解決)に挑戦します。   AWSオンラインプログラムスケジュール 参加にあたって 本プログラムへの参加は、まず基礎知識確認のクイズを受けていただき、その後に事前学習への同意を得たうえで「抽選」となります。 抽選に当選し、参加いただけることになった場合には、事前学習としてAWSの基礎知識を資料と動画（BIGLOBE社員が作成したもの！）で学んでいただくことを推奨しています。さらに、事前学習の理解度をチェックするために、知識確認のクイズもご実施いただけます。 ※筆記用具、インターネット環境、カメラオンでWeb会議可能なPCが必要です。 ※クイズの回答結果やプログラムへの参加可否が、今後の採用選考に影響を及ぼすことは一切ございません。 日程 12/12(木)10:00-17:30（お昼休憩1時間）、12/13(金)13:00-16:30 ※2日間通してご参加ください。 ※抽選結果発表後、当選された方にはご予約の手続きを進めていただけます。なお、定員がございますので、予約は先着順となります。 応募方法 下記URLよりエントリー後、マイページにログインしていただき、Step Navi「AWSオンラインプログラム申し込み」へアクセスし、お申し込みください。 https://mypage.3010.i-webs.jp/biglobe2026/applicant/login/baitai-entry/entrycd/Style ※「初めての方はこちら」より、新規登録をしてください。   AWSオンラインプログラムの魅力 おすすめポイント ・AWS未経験でも安心して参加できる 1日目のハンズオンは少人数のグループに分かれて社員が常時サポートを行うため、AWS未経験の方でも安心して参加いただけます。 ・業務の疑似体験ができる 2日目は2〜3人のチームでシステム不具合への対応に取り組んでいただきます。実際の業務でも問題発生時には複数人で対応するため、業務を疑似体験することができます。 ・社員と接する時間が多く、BIGLOBEの雰囲気がわかる 2日間を通して10名以上のBIGLOBE社員と話したり、ハンズオンやトラブルシューティングに取り組んでいただけます。ラフな座談会も行うので、社風や実際の働き方を知っていただけると好評です。   プログラムへ参加するとこんなことができるようになります ・AWS上での基本的なWebシステム構築 ・BIGLOBE流のふりかえり（仕事以外でもあらゆる場面で役立ちます！）   今年度サマープログラム参加者の声 ・AWSを知らない人でも安心して基礎的な部分を学ぶことができ、AWSの知識を深められるとても有意義なプログラムでした。 ・資料や先輩社員の指導が丁寧で、不自由なくワークを進めることができました 。 ・AWSという現代のインフラクラウドプラットフォームの基幹となる技術に触れることができるため、AWS初心者にはとても良い体験になると思いました 。 ・学生が個人でAWSに触れる機会はあまりなく、ハンズオンで設計構築、トラブルシューティングを経験できるのは本当に貴重だと思いました。 ・実際の業務で使用しているAWS環境でのトラブルシューティングから、社員さんとの座談会など、全体を通して会社理解を深める機会が多く内容のある2日間でした。 ・社員の方とのコミュニケーションを通して、社内の雰囲気や、社員の方の人柄を知ることができるという点でも、距離感が近いプログラムでした。 ファシリテーターからひとこと 上田 彩登 (うえだ あやと) プロダクト技術本部 共通技術部 テクノロジー開発グループ 2023年4月新卒入社 BIGLOBEを知ったきっかけは、ハンズオンベースのプログラムを探していた時です。AWSに関しては、言葉しか聞いたことがありませんでしたが、これからはクラウドを知っておかなければならないと思い、参加しました。 実際に参加してみると、わかりやすい資料とサポート環境が整っていたため、問題なく進めることができました。参加者のレベルがさまざまだったことも良い刺激になりました。 座談会では、先輩社員から普段の業務や社内の雰囲気を聞くことができ、大変良い時間となり、入社のきっかけとなりました。 入社後、全体の新入社員研修が終了した後に、週1回のエンジニア研修が用意されており、エンジニアとして知っておくべきスキルや知識を学ぶことができます。また、資格サポートも充実しており、資格取得をしやすい環境となっています。そのおかげで、2023年9月にAWSソリューションアーキテクト・アソシエイトの資格を取得できました。 少しでも興味があれば、AWSオンラインプログラムに参加してみてください！ みなさまとお会いできることを楽しみにしています！   川浦 哲詩 (かわうら さとし) プロダクト技術本部 ＡＩ・分析推進部 ＡＩ・分析グループ 2023年4月新卒入社 私が就活中にBIGLOBEを知ったきっかけが、このプログラムでした。 最初はAWSについて名前を知っているだけで触れたことはありませんでしたが、このプログラムでは実際に手を動かしながらAWSシステムの構築とトラブルシューティングを体験しました。 初心者でもわかりやすい資料が用意されており、先輩社員のみなさんがどんな質問にも明るく答えてくださったため、AWSについてほとんど知らない私でも楽しく基礎を学ぶことができました。 また、2日間を通して先輩方の雰囲気も知ることができ、座談会では働く環境など気になっていたことを聞くこともできました。そこからBIGLOBEに興味を持ち、入社へと繋がりました。 BIGLOBEは、週に1度の新入社員エンジニア研修があり、資格取得のサポートも充実しています。技術書や参考書なども会社負担で購入可能で、自由に借りることができます。 このように、技術や資格の勉強に最適な環境が整っているため、入社後4カ月程でAWS ソリューションアーキテクト・アソシエイトの資格を取得できました。 エンジニア研修は、他にもネットワーク構築からチーム開発演習まで幅広く実践的な内容が用意されており、楽しみながら技術を学ぶ事ができます！ AWSやBIGLOBEに少しでも興味を持った方、大歓迎です！ぜひ弊社のプログラムにご応募ください。当日は私も参加します！全力でサポートしますので、楽しみましょう！   米沢 大智 (よねざわ だいち) プロダクト技術本部 サービス運用部 運用プラットフォームグループ 2023年4月新卒入社 このプログラムに参加したきっかけは、当時BIGLOBEから内定をもらっていた先輩からの紹介でした。研究室配属より前からAWSとISPに興味があったため、これは行くしかない！と思い、参加しました。 個人的には、こんなことを考えている方は特におすすめです！ ・AWSって聞いたことあるけど触ったことないなー、どういう感じなんだろう ・AWSって設定を間違えるととんでもない額が課金されるって聞いたから触るの怖いなあ... ・この会社ってどんな感じなんだろう、ここでやっていけるかなあ などなど... 私自身このようなことを思いながら参加していましたが、いろいろな情報を手に入れることができて良かった！！と思っています。 2日目の座談会はAWS以外のことも気軽に質問いただける機会ですので、普段知り得ない会社のことや、先輩社員の就活のことなどどんどん聞いてください。答えられる範囲であればなんでもお答えします！AWSを触る経験や会社の雰囲気を感じ、これらの経験が就活の一助となれば幸いです。   みなさまのご参加を心よりお待ちしています！   BIGLOBE新卒採用サイトはこちら！ www.biglobe.co.jp ※ Amazon Web Servicesは、米国その他の諸国における、Amazon.com ,Inc.またはその関連会社の商標です。 ※ 記載している団体、製品名、サービス名称は各社の商標または登録商標です。

.table-of-contents ul { display: none; } ロサンゼルスのデータセンターについて ロサンゼルスデータセンターの存在意義 日本では直接交換できないトラフィックを交換する トランジット価格やピアリングの交渉力を維持する インターネット運用における最新動向を知る どんなデータセンターなの？ 日本のBIGLOBEバックボーンとロサンゼルスはどのように繋がっているのか？ 今回はどのような作業をしたの？ おわりに プロダクト技術本部ネットワーク技術部の山口です。 5月6日〜5月11日の間アメリカ合衆国ロサンゼルスに出張に行ってきました。 この出張で ロサンゼルスのBIGLOBEのデータセンターのネットワーク設備をアップグレード しました。 今回はBIGLOBE社内でもあまり知られていない？ロサンゼルスデータセンターについて紹介したいと思います。 ロサンゼルスのデータセンターについて BIGLOBEのネットワーク機器が動いているデータセンターが海外にあることをご存知でしたか？ BIGLOBEでは以下の図の通りバックボーンネットワークを様々な国（シンガポール、香港、オランダ、アメリカ）へ伸ばしています。 この内、 アメリカのロサンゼルスにだけは物理的なデータセンター があり、 現地にBIGLOBEのネットワーク機器 が存在しています。 他の地域（シンガポール、香港、オランダ）は他の組織とトラフィック交換のための接続（ピアリング）するために日本から現地のインターネットエクスチェンジ までの回線を直接接続している（これをリモートピアリングと呼びます）だけで、物理的なネットワーク機器やデータセンターは存在しません。 BIGLOBEのアジア・北米バックボーン ロサンゼルスデータセンターの存在意義 ロサンゼルスのデータセンターには接続サービスなどのお客様は直接接続されていません。 現地のインターネットエクスチェンジを通じて他の組織とトラフィック交換のため（例えばAmazonなどと）の接続（ピアリング）のみを行なっています。 例にあげたAmazonなどとは日本でも直接接続（ピアリング）してトラフィックを交換することができます。 では、なぜロサンゼルスのデータセンターにBIGLOBEのネットワーク機器を置いているのでしょうか？ 日本では直接交換できないトラフィックを交換する 日本で直接接続できない組織（例えば、アメリカだけに接続ポイントがある組織）との間のトラフィック交換は現地に接続ポイントを 持っていなければ直接トラフィック交換（ピアリング）することはできず、トランジット（お金を払って他の組織にトラフィックを運んでもらう）ことになります。 トランジットを利用するとコストが掛るのは勿論ですが、通信先との間に他の組織が挟まるため、品質のコントロールが難しくなります。 （稀なことではあるが途中で通信が遠回りして遅延が増加したり、パケットロスが発生してしまうこともある） 直接接続 することで 品質のコントロールが容易 になるほか、 トランジットに支払うコストの削減 にもつながります。 また、前述のAmazonなどは日本でも直接接続（ピアリング）できますが、すべてのトラフィックを日本で交換できるわけではありません。 例えばアメリカ地域のトラフィックは日本では交換できず、現地に接続ポイントを持っていなければ、日本で接続していてもトランジットを経由してしまいます。 トランジット価格やピアリングの交渉力を維持する 日本にISPは数多くありますが、海外にデータセンターを構えることのできる通信事業者やISPは非常に限られています。 公開されている情報でわかる範囲で調べてみたところ、海外のデータセンターにネットワーク機器を設置している通信事業者やISPは2桁あるかないかではないでしょうか。 日本国内のみならず、世界でネットワークを構築し運用することのできる、それなりの能力や規模があり、世界の事情を知っているISPと見られるでしょう。 ピアリングの交渉やトランジットの調達価格の交渉 をする際に、これが 有利 に働くことがあるかもしれません。 インターネット運用における最新動向を知る アメリカはIT企業の数が非常に多く、新サービスや新技術がいち早く提供され、多くの情報が集まります。 また、 アメリカ西海岸は世界で一番トランジットの価格が安い地域 と言われており、ここにデータセンターがあることでしか得られない情報があります。 今回は構築作業の後にロサンゼルス市内から30km程はなれた街にある現地のCDN企業のオフィスを訪問して先方のエンジニアとディスカッションを行ってきました。具体的な内容は機密情報も含まれるためこの場では差し控えますが、日本では なかなか入手できない最新の情報を入手 することができました。 現地にデータセンターがあることで情報収集や技術交流ができるというのも大切なポイントです。 どんなデータセンターなの？ ロサンゼルスの中心部のダウンタウンにあるOne Wilshireという名前のビルの中にデータセンターはあります。 このビルの中でCoreSite社という会社がデータセンターサービスを提供しています。 One Wilshireはとても古いビルで1966年に建設され当時はオフィスビルとして使われていました。 その後、1990年代に大手通信会社が入るようにより、データセンターへと変貌を遂げることになりました。 現在では300社以上のインターネット企業組織がこのデータセンターに接続をしています。 そのため、世界でも有数のインターネット企業の相互接続ポイントになっています。 このような接続ポイントは世界中にありますが、300社以上が集まる規模の場所は日本には無く、世界トップ10に入ります。 データセンター内で撮影した写真は関係者以外に公開できないため、外観の写真をご覧いただければと思います。 One Wilshire ビル外観 日本のBIGLOBEバックボーンとロサンゼルスはどのように繋がっているのか？ 日本との間は通信キャリアの接続する専用線サービスを契約しており、海底ケーブルを使って接続されています。 実はこの海底ケーブル、切断され障害となることが高頻度で発生し、切断されると船が修理に行くため復旧までに結構な時間が掛かります。 （切断される理由は様々ですが、底引網など漁業による切断、海底の地殻変動による切断などがあります） そのため、BIGLOBEでは複数の通信キャリア（ 複数の海底ケーブルシステム ）を利用することで 冗長性を確保 しています。 今回はどのような作業をしたの？ 今回の作業の主な目的は 需要対応 のための 機器の交換と回線の増強と冗長性の強化 です。 お客様とトラフィックの増加に伴い各接続の帯域が不足しはじめており今後の需要に耐えられない状態となりつつありました。 帯域が不足し回線の輻輳が発生すれば品質が大きく低下することになります。そのため、以下の通り回線の増強を行いました。 Equinix IX SanJose（インターネットエクスチェンジ） 20Gbps ⇒ 100Gbps BBIX US West（インターネットエクスチェンジ） 10Gbps ⇒ 20Gbps 増強に伴い、利用しているネットワーク機器も老朽化が進んでいたため、 最新モデルの機器に交換 を行いました。 また日本との間は今まで東京のみと繋がっていましたが、 東京と大阪に繋ぐ構成に変更 しました。 これにより、仮に災害などで東京が全断するような問題が起きても大阪経由でロサンゼルスとの通信が維持できます。 また、僅かではありますが西日本のお客様から見ると、ロサンゼルスへの通信が東京を経由しなくなるため遅延を削減することができます。 作業前の構成 作業後の構成 おわりに これを機に、BIGLOBEが国際ネットワークを持っており、これが安価で高品質なインターネット接続をお客様に提供できることに寄与していることを知って頂けますと嬉しく思います。 ※ 掲載されているイラスト、写真に関する著作権はBIGLOBE又は第三者が有し、許諾なく利用できません。 ※ Amazon は、Amazon.com, Inc.またはその関連会社の商標または登録商標です。

GitHubをテーマにした社内LT大会を開催し、新たな発見と学びが得られました。楽しみながら技術力を磨き、エンジニア同士のつながりを作っています。 はじめに LT大会 スクラム開発のタスク管理にGitHubはどうですか？ GitHub Projectsでタイムトラッキング Pagesで業務改善しよう nektos/actでGitHub Actionsをローカルでも動かしたい IntelliJ IDEAでシームレスなPRレビュー 『GitHub CI/CD実践ガイド』を出版した話 （野村友規さん） おわりに はじめに BIGLOBEの網干です。2024年6月にGitHubをテーマにした社内ライトニングトーク（LT）大会を開催しました。 それぞれのLTでは GitHub Projects GitHub Pages GitHub Actions Pull Requests といったGitHubの様々な機能を活用しながら、自分たちの仕事をどう効率化しているかを共有しました。 この記事ではそれぞれの発表の概略を紹介していきます。私たちが楽しみながら技術力を磨きつつ、技術ネタを通じて横のつながりを作っている様子をお伝えできれば幸いです。 LT大会 スクラム開発のタスク管理にGitHubはどうですか？ Kさんのチームは、スクラム開発にGitHub Projectsを活用しています。GitHub Projectsを活用することでタスクや進捗の把握がしやすくなり、スクラム開発の透明性を向上させることができました。 具体的には次の工夫をしています。 ステータスの設定 : Issueに設定するステータスとして「バックログ」「スプリントバックログ」「作業中」「レビュー中」「クローズ」を設定し、Issueが現在どのステータスなのかを明確化しました。 カスタムフィールドの設定 :「優先順位(1番目、2番目、バッファなど)」、「スプリント」、「ストーリーポイント」をIssueに設定し、各タスクの重要性やスプリント内の位置づけを明確化しました。 ボードのカスタマイズ : ステータスごとにカラムを設定(ボードを縦に分割)し、優先順位に応じてタスクをグループ化(ボードを横に分割)することで、各Issueのステータスと優先順位がひと目でわかるようにしました。 バーンアップチャート : カスタムフィールドとして「スプリント」「ストーリーポイント」を設定することで、GitHub ProjectsのInsights上にバーンアップチャートを表示し、進捗を可視化しました。 GitHub Projectsでタイムトラッキング Sさんも普段の業務でGitHub Projectsを利用してタスク管理をしています。Sさんは「どのタスクにどれだけ時間をかけたかの記録をつけたいが、忘れてしまう」という課題から、普段通り仕事をしているだけで作業時間を記録できるツールを作成しました。 作成したツールはGitHub Projectsのボードレイアウト上でIssueのカラムを移動するだけで、Googleカレンダーに作業時間を記録します。Issueの変更をトリガーにしてWebhookを送信しGoogle Apps Scriptの関数を起動、Googleカレンダーにタスクの作業時間を記録します。LTではツールの全体像やWebhookにIssueのグローバルノードIDを追加する設定、GraphQLでGitHub API v4からIssue情報を取得する方法について詳しく紹介していただきました。 Pagesで業務改善しよう 次はGitHub Pagesを使って、自作ツールを手軽に公開した話です。Fさんは日常業務を効率化するため、マインドマップを使ったタスク出しとガントチャートを用いた進捗管理を組み合わせるツールを開発しました。このツールはブラウザ上で動作し、GitHub Pagesにデプロイされています。Fさんのこだわりは、テキスト入力でガントチャートとマインドマップまで作れる点だそうです。 GitHub Pages上にデプロイしているツールのスクリーンショットです。テキストボックスに図の出力用のフォーマットで文字列を入力し、「更新」ボタンを押すことでページ下部にガントチャートとマインドマップ（Work Brakedown Structure：WBS）が同時に出力されます。 nektos/actでGitHub Actionsをローカルでも動かしたい GitHub Actionsを活用してCI/CD環境を構築しているOさんは「GitHub Actionsのワークフローの動作確認をローカル環境でしたい」と考え、 nektos/act を使いはじめました。GitHub Actionsをローカル環境で動作させるGo言語製のツールです。LTではnektos/actの導入にまつわる「ハマりポイント」を詳しく解説し、動くデモも見せてくれました。GitHubの環境を完全にエミュレートしているわけではない点に注意は必要ですが、開発がとても捗るとのことです。 IntelliJ IDEAでシームレスなPRレビュー EさんにはIntelliJ IDEAの機能を活用したPull Request（PR）レビューのメリット、デメリットを紹介していただきました。EさんはJavaのシステムを担当していて、IDEにはIntelliJ IDEAを利用しています。GitHubのWeb上でも簡単なPRレビューはできますが、プログラムを深く読みたい場合などIntelliJ IDEAでソースコードを確認したいことがあります。実際にIntelliJ IDEAでPRレビューをしたところ、メリットは変更ファイルの一覧や変更点の確認、コメントの確認や送信、「Mark as Viewed」などの操作ができる点でした。一方、デメリットはPRに貼られた画像やPRに紐づいているIssueが確認できないことだったそうです。 『GitHub CI/CD実践ガイド』を出版した話 （野村友規さん） 弊社ではGitHubを使ったCI/CD環境を構築しており、そのコンサルティングを野村友規さんに依頼しています。野村さんには特別講演として『GitHub CI/CD実践ガイド』の紹介や出版裏話について発表していただきました。 おわりに LT大会のあとにはそのまま懇親会を開催しました。参加者はピザやお酒を口にしながらLT大会では話しきれなかったことなど熱く語り合い、会は大盛況のうちに幕を下ろしました。 今回のLT大会と懇親会で技術者の知見を共有できたことはもちろん、部署同士の横のつながりが一層強くなりました。 今後もこのような技術者が楽しく知見を共有できるイベントを開催していきます。 ※ GitHubは、GitHub, Inc.の米国およびその他の国における商標または登録商標です。 ※ Google は、Google LLCの商標です。 ※ IntelliJ は、JetBrains s.r.o.の商標または登録商標です。 ※ 記載している企業、団体、製品、サービス等の名称は各社またはその関連会社の商標または登録商標です。

（前列）2023年度入社新人エンジニア　（後列）2024年度新入社員 こんにちは。BIGLOBE Style編集部の吉田です。 BIGLOBEの開発部門（プロダクト技術本部）では、「新人エンジニア育成プログラム」を1年かけて実施しています。 今回の記事では、そのプログラムを終えた7名のエンジニア（2023年4月入社）による成果発表会の様子をレポート形式でお届けします。入社時からどのように成長したのか、どうぞご覧ください！ ビッグローブ本社コミュニケーションスペース「Daichi」にて はじめに 新人育成プログラムとは 成果発表～何を経験し、どのような学びを得たか～ 幹部から総評 2026年卒向け新卒採用について はじめに この成果発表会は、1年間お世話になったコーチや上司、幹部の方々に成長ぶりをアピールする節目のイベントです。発表後には上司や幹部からフィードバックが得られる貴重な機会でもあります。 そして、今年度の新入社員も聴衆として参加し、1年後の自分の姿をイメージしながら、しっかり目に焼き付けます。 新人育成プログラムとは 成果発表の前に、新人エンジニア育成プログラムの背景を説明します。このプログラムは、週1日の集合研修と週4日のOJT（On the Job Training）を1年間続けます。 BIGLOBEが提供するインターネットサービスは、今や社会に欠かせないインフラとなっています。そのため、お客さまに影響のあるミスはゼロにしなければいけません。しかし、人は失敗から多くを学びます。そこで、安心して失敗できる場として集合研修を用意しました。 このプログラムでは、集合研修で基礎スキルやBIGLOBEのノウハウを学び、複雑なシステムを理解するための土台を作ります。研修では、実際に手を動かすことを重視し、失敗を経験しながら同期と共に学びを深めます。そして、配属先でのOJTで業務を通じて実践的なスキルを身につけ、成長を促します。 なお研修の講師を務める先輩社員は、かつてこの研修を受講した新人です。23年度から「教わったら教える」というサイクルを確立し、このプログラムを継続可能にしました。講師自身から「教えることで、自分も学びを深められた」といったポジティブなフィードバックを得ています。 ▼関連記事をチェック style.biglobe.co.jp style.biglobe.co.jp また、並行して資格取得にもチャレンジし、さまざまな資格を取得しました。 取得した資格の一部をご紹介 Amazon Web Services, Inc. 認定資格 AWS Certified Solutions Architect - Associate AWS Certified Developer - Associate AWS Certified SysOps Administrator - Associate Scrum Inc.認定資格 Registered Scrum Master、Registered Product Owner そして、育成プログラムの集大成は、チーム演習開発です。数名のチームに分かれ、1年間学んできた工程をアジャイルに繰り返しながらプロダクト開発に取り組みます。主に、社員のお困りごとを解決してくれるプロダクトを試作してくれました。 23年入社メンバーが試作したプロダクト ・エンジニア志望学生向けのインターンシップで利用する Infrastructure as Code（IaC） の学習アプリ ・社内にある大量の技術書の貸し借りを管理するシステム ・フリースペースで開催する会議の場所を簡単に共有するシステム さて、それでは23年入社メンバーがどのように成長したのか、抜粋となりますがご紹介します！ 成果発表～何を経験し、どのような学びを得たか～ 川浦 哲詩 (かわうら さとし) プロダクト技術本部   サービス開発２部   アジャイル開発１グループ 担当業務：サービス契約管理システムの開発・運用 川浦は、お客さまが申し込まれたサービスの契約状態を管理するシステムについて、新しいAPIの要件定義からリリースまでを担当。このAPIは社内の別の部署が呼び出すもので、実際に利用してもらったところ、必要な機能が欠けていることが判明。要件定義からやり直すという手戻りを乗り越えてのリリースとなりました。 この経験から、利用者サイドの視点を考慮し、開発に取り組む前に要件について十分にコミュニケーションをとることの重要性を学んだと語りました。 田口 敏宏（たぐち としひろ） プロダクト技術本部　副本部長 田口： 利用者視点での開発を1年目から学んでいただけたのはとても良かったです。今後はより重要なシステムや、お客さまに直接関わるシステムに携わると思います。その視点を忘れずに今後も成長を続けてください。 上田 彩登（うえだ あやと） プロダクト技術本部　共通技術部　テクノロジー開発グループ 業務： AWS移行・クラウドネイティブ化推進、AWS、オンプレ、OS、ミドルウェア、データベースなど共通基盤の安定運用維持 上田は、担当業務のなかから、社内システムのクラウドネイティブ化とAWS利用料削減を中心に発表。まず、社内システムのクラウドネイティブ化についてはサーバーを撤廃し、IaCを導入することで障害復旧を容易にしました。さらに、今後の運用・保守を考慮してContinuous Integration / Continuous Deployment（CI/CD）を導入。この結果、OSのアップデートが不要となり、障害復旧や運用・保守の工数を削減し、3割のコスト削減を可能としました。 次に、AWS利用料の削減施策については、勉強会やハンズオンの開催、削除対象を特定するプログラムの作成など、多角的なアプローチを実施。その結果、大幅な削減対象リソースの発見につながったという成果を報告しました。 南 雄一（みなみ ゆういち） 執行役員　兼　プロダクト技術本部　副本部長 南： 利用料削減は全社的に大きく貢献してくれました。学びに関してですが、研修や資格など体系だったものを学ぶのはとても大事です。業務と並行して、社内のスキルアップ支援制度を利用しながら、今後もぜひ続けてください。また、他社の取り組みを見ることでもスキルを高められるので、社外にも目を向けてチャレンジしてください。 大田原 和輝（おおたはら かずき） プロダクト技術本部　ネットワーク技術部　開発グループ 業務内容：Domain Name System（DNS） / ロードバランサー / IPv4 over IPv6、NAT64基盤の設計・構築・運用 マンションISPのシステム運用やDNSサーバの構築・運用を担当している大田原は、さまざまな経験を通して変化していった心境に焦点を当て発表。入社時は人に聞くのも教えるのも苦手だったという大田原ですが、上司や先輩社員から学ぶうちに、「知ること」がどんどん楽しくなっていったといいます。 さらに、自ら調査した結果を発表したJANOGなどの社外活動を通じて「他社社員に負けたくない」という気持ちが芽生え、何事にも臆さずチャレンジする精神が身に着いたと語りました。   南： 1年目にも関わらずJANOG登壇に自ら手を挙げてチャレンジしてくれたり、テレビ出演を通じてビッグローブ光10ギガサービスの広報も行ったりと、多くの経験を積んでくれました。また、ネットワークに特化した新たなインターンシップも提案し、全社にコミットする重要なKPIとなっています。大田原さんのグループは、インフラ部門の中でもチャレンジングなことに取り組んでいるグループです。その中でも遅れをとらずに成果をだしてくれました。引き続き頑張ってください。 米沢 大智（よねざわ だいち） プロダクト技術本部　サービス運用部　運用プラットフォームグループ 担当業務：監視システムの維持管理、改善 米沢は、監視システム更改にまつわるほぼ全ての工程（製品調査、基本方針策定、要件定義、ベンダー折衝、評価環境構築、納品物確認、社内調整）を、サポートを受けつつ担当。社内システムの現状把握や理想的なシステム像の定義ができるようになるまでは、ベンダーとの折衝に苦労するも、業務を通じて、認識のすり合わせの重要性や、社外コミュニケーションのスキル、異なる視点から物事を見る力を身につけたと語りました。 また、資格取得の過程では、AWSを実際に操作し、基礎力と設計に対する理解を深めました。   南： サービス運用部は全てのサービスを支える重要な役割を担っていますので、これからもしっかりやっていただけることを期待しています。理想的なシステムの定義は非常に大事です。目の前のやるべきことに捉われず、バックキャストで考えると成長につながりますので引き続き頑張ってください。 橋本 ゆう（はしもと ゆう） プロダクト技術本部　サービス開発2部　アジャイル開発3グループ 業務：Salesforce関連の開発、コンタクトセンターの管理 橋本は、Salesforce関連の開発やコンタクトセンターの管理に従事。ビッグローブ光などのサービス案件、基盤対応、コンタクトセンターからの改善要望や機能開発など、上流から下流まで幅広い経験を積みました。 その中で、BIGLOBEモバイルの物流業者変更のプロジェクトマネージャーとして参画した案件を発表。当初軽い気持ちで引き受けたものの、予期せぬ問題が多発するという苦労を経験しました。しかし、その困難を乗り越えた経験を通じて、関係者とのコミュニケーションのとり方やトラブル時の対応、諦めない精神を学んだと語りました。   田口： 橋本さんは説明力、説得力があり、新入社員とは思えない活躍をされています。物流業者変更プロジェクトはもうすぐ完了です。チーム一丸となって成功に導いてください。（現在リリース済／取材時5月） 関谷 彪（せきや ひょう） プロダクト技術本部　サービス開発2部　アジャイル開発2グループ 業務：ビッグローブ光 販売管理システム 運用改善 関谷は、ビッグローブ光を10ギガに対応させる上で必要となる運用作業を大幅に改善した成果について発表。具体的には、ツールを開発することで、月当たりに作業できる件数を5倍以上に向上させました。また、APIを改修することで運用効率を改善し、27時間/月の運用工数を削減。さらに、バッチ処理を改修し、処理完了までにかかる時間を1/21に短縮しました。 配属前は業務やシステムに関する知識と自信が不足していたが、配属後は改善案件を通じてシステム設計や技術を深く学び、基本設計からリリースまでを経験し定量的な成果を上げることができたと語りました。   田口： 関谷さんが開発したシステムは、ビッグローブ光10ギガサービスのリリースに大きく貢献した機能です。BIGLOBEのシステムは長年やってきたことによりブラックボックス化しているものもあります。そんななか頑張ってリリースできたことは大きな成果です。また、アジャイルの考え方は大事です。チームで仕事をしていくなかでスクラムマスターの資格を活かしながら、業務の中にアジャイルな動き方を広げていってください。 山口 樹（やまぐち いつき） 全社横断　サービス企画部　プロダクト１グループ 業務：サービス化プロセス標準化事務局運営、投資予算管理 山口は企画部門に所属し、システム開発に必要な投資予算を管理。一つのサービスは複数のシステムが連携して実現しています。そのため、投資判断はサービス単位で実施すべきところ、配属当時はシステム単位で予算管理がされていました。そこで、予算の管理単位をシステムからサービスへと変更し、各サービスに割り当てる予算の妥当性を判断しやすくしました。これにより、案件にかかる予算が変動しても効率的に調整できるようになり、次年度の予算精度も向上しました。 当初苦労した点を克服し、今ではタスク分解や役割の主体的な把握、基本的な会計知識の習得、効果的な資料作成ができるようになったと語りました。 高宮 展樹（たかみや のぶき） 取締役執行役員常務　兼　プロダクト技術本部　本部長 高宮： 予算管理はとても大変です。仕組みを変えようとすると、付随する多くのものを変えないといけないので、今まで変えられなかった部分です。そこを今回、山口さんが変えてくれました。この新たな仕組みでさらに事業を伸ばし、コストを抑えていけるよう、さらに一歩踏み込んで変えてくれることを期待しています。一緒に事業成長に取り組んでいきましょう。 幹部から総評   高宮： 1年間お疲れさまでした。どの発表を聞いても、研修、資格取得、OJTなど周りの人からノウハウを得て、事業貢献につなげていただきました。内容はさまざまですが、どの活動も成果につなげられていることが頼もしく思えました。新人は卒業しますが、今後は若手社員として必要なスキル、ノウハウをもう一度見つめ直して、次の成長に向けたアクションを起こしてください。社会人生活はこのあと30年以上続きます。いまの成長を続けられると、業界でナンバーワンのエンジニアになれますので、ぜひ頑張ってください！ 2023年度入社新人エンジニア成果発表会のレポートは以上です。 今年度（2024年）からはKDDIグループのソフトウエア開発研修も加わるため、さらなるスキルアップが期待されます。みなさんの活躍を楽しみにしています！ 2026年卒向け新卒採用について 現在、BIGLOBEでは2026卒向けの新卒採用活動を実施中です。 マイページへご登録いただいた方へは、メールで採用活動のお知らせなども行っておりますので、 少しでもBIGLOBEに興味をもっていただけた方は、ぜひ下記URLより登録をお願いいたします。 https://mypage.3010.i-webs.jp/biglobe2026/applicant/login/baitai-entry/entrycd/Style ※「初めての方はこちら」より、新規登録をしてください。 （マイページ会員規約同意の確認ページへ遷移します。同意いただけますと、マイページご登録画面へと遷移します。） www.biglobe.co.jp   ※ Amazon Web Servicesは、米国その他の諸国における、Amazon.com, Inc. またはその関連会社の商標です。 ※ Salesforceは、Salesforce.com, Inc.の米国およびその他の国における登録商標または商標です。 ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。