はじめまして。エンタープライズ第二本部 プラットフォームエンジニアリング部 2年目の菊池祥汰です。業務ではAIサポートセンターとして 生成AI / LLM 活用案件やdJグループ内の生成AI利活用推進などを行っており、プライベートでも積極的にAI課金をして試しているAIフリークです。 この記事は、社内に幾多ある勉強会のひとつである『25卒技術会』での発表内容をもとに執筆されています。 『25卒技術会』では隔週火曜日に会議室に集まり、ブックリーディングと自由テーマ発表の2軸で各々の学びを共有し合っています。このたび、外部向けの施策として自由テーマ発表から不定期でテックブログを書いていく運びとなりました。ちなみに、この会の主催者はテックブログ常連でもある同期の大岡叡さんです。今後、下記の技術会メンバーからも記事の投稿がある予定ですので、お楽しみに。 大岡 叡 ／菊池 祥汰 ／ 伊藤 真幸 ／ 植木 信輔 ／ 上原 辰徳 ／ 今橋 輝 ／ 渡邉 真太郎 ／ 段下 幸太郎 自律駆動する部下は実現するか — OpenClaw という予兆 ローカル LLM の 3 つの強み 目指す世界 — 24 時間 365 日 動く株式エージェント ローカル LLMの現在地を探る 道具立て — Ollama / Gemma 4 ベースライン — 単純な線形回帰による数学的解決 実験 結果と考察 — Gemma 4 vs Gemini 現在地の見立てと展望 おわりに 2026/06/04追記 自律駆動する部下は実現するか — OpenClaw という予兆 2026 年の年明けから、 OpenClaw （旧 MoltBot） と呼ばれる能動的な AI エージェントが話題になっています。 OpenClaw は、特定のディレクトリに操作権限を与えると、AI が「次に何をすべきか」を自分で考えながら、24 時間 365 日、自律的に動き続けるタイプのエージェントです。人間が一手ずつ指示するのではなく、目的だけ渡せば手段を自分で組み立てていきます。 目的を渡せば、AI が「次にすべきこと」を自分で考え、実行し、結果を見て改善する。これが 24 時間 365 日回り続ける AI の操作をいちいち承認する操作も不要。AIの成果物を確認しレビューする 人間という最大のボトルネックを排し 、AI を本当に「 自律駆動する部下 」のように位置づけられる可能性が見えてきました。こうした動きは、すでに一人歩きを始めており、AI エージェントだけが集う SNS「 Moltbook 」なども話題を呼んでいます。Reddit のように投稿やコミュニティが並ぶのに、書き込むのはすべて AI エージェントで、人間は観察者としてしか入れません。サービス開始から数日で150万を超えるエージェントが集まり、その中では AI 同士が共同体や、ときに宗教めいたものまで自発的に作り始めたと 報じられ ています。 AIはチャットボットとして人間に律速されるフェーズを脱し、エージェント駆動する時代へとのシフトが始まりつつあります。 その一方で、大きなリスクがあります。それが API コスト です。AI を長時間・高頻度で回すほど、ランニングコストは跳ね上がっていきます。これは特に金融系のユースケースでROIを測定する際に重くのしかかってきます。 必然的に、 ローカル LLM が選択肢に上ってきます。通常私たちが利用している ChatGPT や Claude（本記事ではまとめてクラウド LLM と呼びます）は、各社のサーバ上の計算資源（メモリや GPU など）を使って動いています。便利な反面、入力は社外に送られ、使うほど従量課金が積み上がっていく。これを自分の手元のマシンだけで完結させようというのが、ローカル LLM の発想です。 ローカル LLM の 3 つの強み 私がローカル LLM の価値として最も強く押し出したいのは、次の 3 点です。 データが外部に出ていかない（セキュア） — クラウド API は入力がすべて外部に送信されます。機密情報や個人データ、API キーを扱う場合、ともすれば致命的になりえます。ローカルなら、扱うデータは自分の環境から出ません。 完全自律で回しても API コストが爆発しない — 長時間・高頻度で動かすほどクラウド API の従量課金は膨らみます。最近は各種AIベンダーも投資を回収するフェーズに入ってきており、円安も加わってクラウドAPIのコスト体系はかなり向かい風です。ローカルLLMなら、追加コストは電気代だけ。円安の煽りを受けにくいだけでも儲けものです。 買い切った GPU を遊ばせない — これは減価償却的な観点ですね。ゲーム用に買った GPU をAPI 利用料の節約という観点で使い回すことができれば、買い切りの出費を長く活かし続けられます。 ローカル LLM の 3 つの強み。（1）データが外に出ない （2)API コストが爆発しない （3）買い切った GPU を遊ばせない 目指す世界 — 24 時間 365 日 動く株式エージェント さて、この自律駆動エージェントの終着点を、私は24 時間 365 日、世界中のニュース・企業のプレスリリース・今朝の報告書を監視し続け、 株の自動売買を行うエージェント だと見ています。短期投資は分刻み・秒刻みで状況が動くので、「いま買いか、買いでないか」を常に判断させたい＋低コストで回しっぱなしにしたいという需要があります。ローカル LLM の優位性は明確です。 加えて、セキュリティ面でも、ローカル LLMを用いれば自身のポートフォリオや API キーが外部に流出するリスクを、限りなくゼロに近づけられます。金融データを扱う以上、セキュリティは最優先事項です。ローカル LLM の性質と、このタスクの要件は強く噛み合います。 最も重要なのが ランニングコスト です。API 料金が発生すると、コストに見合うリターンを得なければならず、強気（ハイリスクハイリターン）な投資を余儀なくされてしまいます。これは運用手数料の高い投資信託を保有しているときの感覚に近く、最も忌避すべき条件です。だからこそ、追加コストを電気代だけに抑えられ、なおかつまともな回答精度が得られるのであれば、ローカル LLMは非常に合理的なブレインとなりうるでしょう —— まともな回答精度が得られるのであれば、ですが。 一方で、現実にそういった話はなかなか聞きません。なぜなのでしょう。前置きが長くなりましたが、今回の記事ではここに切り込んでいこうと思います。 ローカル LLMの現在地を探る 投資エージェントをいきなり走らせるのは無理があります。買いと判断した銘柄が上がったか下がったか、その答え合わせには数か月かかりますし、コーディングも大規模になってしまいます。 そこで本記事は、ローカル LLM の現在地を知るための実験として、 物件のスペックから賃料を予測する という擬似的な経済価値判断タスクを解きます。無数の物件スペック情報から適正な価格を予測し、その予測価格と実際の価格を照合して、コスパの良い物件を検出する。スペックから想定される賃料より実際の賃料が安ければ、それはコスパが良い物件とみなし、ユーザーに提案するというものです。 両者の構造を並べると、次のように対応します。 ステップ 物件コスパ判定（題材） 株式自動売買（本命） 外部データ ローカルにキャッシュした物件情報 株価 API・ニュース・朝の報告書 LLM の価値判断 スペックから適正賃料を予測 情報から買い/売り/様子見を判断 指標化 コスパスコア（実価÷予測） 投資シグナル 正解突合 即時 数日〜数か月後 株価予測は検証に長い期間が必要です。一方、この物件タスクは、構築と答え合わせのサイクルが短く、実装も容易です。ローカル LLM の現在地を知る、という目的にはこちらが合っていました。 道具立て — Ollama / Gemma 4 ローカル LLM 基盤には Ollama を用いました。Ollama はよく「Docker for LLM」と呼ばれます。実際、開発者は元 Docker のエンジニアで、 ollama pull でモデルを取得し ollama run <model> で対話を始める操作感は Docker そっくりです。 起動すると、 localhost:11434 に REST API サーバーが立ちます。OpenAI / Anthropic 互換のエンドポイントを備えているため、既存コードの接続先を差し替えるだけでローカルモデルに切り替えられます。 モデルは Gemma 4 を用いました。Google が 2026 年 4 月に公開した オープンウェイトのモデル で、Gemini と同じ研究基盤から生まれた、画像も扱えるマルチモーダルモデルです。 Gemma 4 の特徴として MoE（Mixture of Experts、混合エキスパート） の採用があります。今回の主役 26B は、総パラメータが約 26B ありながら、推論時に実際に使うのは約 3.8 B だけです。すなわち、大型モデルの賢さを、より軽い計算量で出せるというわけです。 もうひとつの個性が、 量子化 との相性です。Gemma 4 は、いずれ圧縮されることを見越して学習する QAT（Quantization-Aware Training、量子化を考慮した訓練）を採っています。おかげで、重みの精度を 16 bit から 4 bit へ落としても品質の劣化が小さく、必要メモリを 4 分の 1 ほどに圧縮できます。本記事でローカルに落とした 4-bit 量子化版（ gemma4:26b ）も、この仕組みの上に成り立っています。 Ollama で扱える主なサイズは、次のとおりです。 Ollama タグ 構成 パラメータ（推論時 / 総） サイズ（4-bit） コンテキスト 位置づけ gemma4:e2b 軽量 2.3B / 5.1B 7.2 GB 128K 最小・スマホ等の省メモリハード向け（本実験では未使用） gemma4:e4b （= latest ） 軽量 4.5B / 8B 9.6 GB 128K 軽量・まず試した gemma4:26b MoE 3.8B / 25.2B 18 GB 256K 中型・今回の主役 gemma4:31b Dense 30.7B / 30.7B 20 GB 256K 最大・最高性能 整理すると、Ollama と Gemma 4 の関係は次の図のようになります。Ollama がローカル LLM の実行基盤、Gemma 4 がその上で動くモデル本体です。 Ollama は実行環境、Gemma 4 はその上で動くモデル。クラウドに送らず、すべてローカル PC 内で完結する 題材アプリ「大田区コスパ物件ハンター」は、Claude Code を使った Vibe Coding で作り、UI は Streamlit でさっと組みました。物件データは各サイトの利用規約に配慮し、あらかじめローカルに保存しておいたキャッシュ（CSV）を入力として扱います。これを読み込み、各物件の相場家賃を LLM に予測させ、実賃料 ÷ 予測でコスパスコアを出すだけのアプリです。スコアが低いほど割安で、0.85 を下回った物件を「お買い得」としてユーザに提案します。 Streamlit で実装したアプリケーションUI。結果はローカル実行した gemma4:26b （直列）のもの。30 件の処理に約 10.9 時間を要した ベースライン — 単純な線形回帰による数学的解決 LLM を並べて競わせても、「どれもそれなりに賢い」で終わってしまうと考え、賃料を専有面積と駅からの徒歩分数の 2 変数だけで説明するシンプルな線形回帰モデルを用意し、ベースラインとすることで、各 LLM の推論能力を定量的に評価しました。 評価用の 30 件とは別に訓練用サンプル 200 件を用意し、最小二乗法で式を一本だけ当てはめました。 賃料(万円) ≒ 0.1898 × 専有面積(㎡) − 0.2021 × 徒歩(分) + 11.26 間取りも築年数も使わない非常にシンプルな式での実装です。訓練 200 件と評価 30 件は 1 件も重なっておらず（out-of-sample）、LLM 側も同じ 30 件を学習していないので、比較はフェアです。 精度は MAE（平均絶対誤差）・MAPE（平均絶対誤差率）・バイアス（誤差の符号付き平均。予測が高めか低めかの偏り）の 3 つで測り、コストはローカルを電気代換算（350 W × 31 円/kWh）、API をトークン単価に統一して記録しました。 そして LLM 側にも、同じ土俵に立ってもらいます。各物件について実際に投げているプロンプトは、次の全文です。素朴に「相場を教えて」と尋ねるのではなく、データから導いたアンカー（基準値と補正係数）を持たせ、例にならって 5 ステップの計算過程（Few-shot + Chain-of-Thought）を踏ませる作りにしています。 あなたは東京都大田区の賃貸相場に詳しい不動産アナリストです。 以下の推論例(例1〜例3)と同じ形式で step1→step5 を順に計算し、最後に賃料を算出してください。 アンカーは大田区2DK/2LDK 117件の訓練データから多重回帰で抽出した実データ係数です。 # 推定アンカー (基準: 中位駅×2LDK×3-5階建×築10-20年×徒歩10分 → 0.33 万円/㎡) ## 駅tier - 上位 (大森・大森町・蒲田・京急蒲田・洗足池): ×1.10 - 中位 (馬込・西馬込・池上・武蔵新田・千鳥町・梅屋敷・大岡山 等): ×1.00 - 下位 (雑色・矢口渡・平和島・下丸子・石川台・田園調布): ×0.90 ## 間取り - 2LDK: ×1.00 / 2DK: ×0.95 ## 階建 - 1-2階建(木造想定): ×0.88 / 3-5階建: ×1.00 / 6階建以上(RC想定): ×1.17 ## 築年 - 築0-10年: ×1.12 / 築10-20年: ×1.00 / 築20-30年: ×0.95 / 築30年+: ×0.92 ## 徒歩 - 徒歩10分基準で ±1分あたり ∓1% (例: 徒歩6分 → +4%、徒歩14分 → -4%) # 推論例(この5stepフォーマットを必ず踏襲) ## 例1: 蒲田駅 徒歩6分 / 2LDK 55㎡ / 築8年 / 8階建 step1 駅tier = 0.33×1.10 = 0.363 (蒲田=上位) step2 間取り = ×1.00 = 0.363 (2LDK) step3 階建 = ×1.17 = 0.425 (8階建 → RC想定) step4 築年 = ×1.12 = 0.476 (築8年 → 築0-10年) step5 徒歩 = ×1.04 = 0.495 (徒歩6分 → +4%) 賃料 = 0.495 × 55 = 27.2万円 推定家賃: 27.2万円 ## 例2: 池上駅 徒歩10分 / 2DK 42㎡ / 築22年 / 7階建 step1 駅tier = 0.33×1.00 = 0.330 (池上=中位) step2 間取り = ×0.95 = 0.314 (2DK) step3 階建 = ×1.17 = 0.367 (7階建 → RC想定) step4 築年 = ×0.95 = 0.349 (築22年 → 築20-30年) step5 徒歩 = ×1.00 = 0.349 (徒歩10分 → 基準) 賃料 = 0.349 × 42 = 14.7万円 推定家賃: 14.7万円 ## 例3: 雑色駅 徒歩14分 / 2DK 40㎡ / 築32年 / 2階建 step1 駅tier = 0.33×0.90 = 0.297 (雑色=下位) step2 間取り = ×0.95 = 0.282 (2DK) step3 階建 = ×0.88 = 0.248 (2階建 → 木造想定) step4 築年 = ×0.92 = 0.228 (築32年 → 築30年+) step5 徒歩 = ×0.96 = 0.219 (徒歩14分 → -4%) 賃料 = 0.219 × 40 = 8.8万円 推定家賃: 8.8万円 # 推定対象物件 - 間取り: {間取り} - 専有面積: {専有面積(㎡)}㎡ - 最寄り駅: {最寄り駅} {徒歩N分} - 築年数: {築N年} - 階建: {階建} 上記5stepを順番に計算し、**最終行に厳密に** `推定家賃: <数値>万円` (小数1桁) の形式で1値だけ出力してください。 ※ プロンプト冒頭のアンカー（基準 0.33 万円/㎡ と各補正係数）は、線形回帰ベースラインの訓練に使った 200 件と同種の サンプルに多重回帰をかけ、統計的に抽出した実データ係数です。つまり、ベースラインと同じ訓練データの知識を LLM 側にも与えたうえで勝負させています。 実験 検証環境は以下のとおりです。 OS: Windows 11 Home / CPU: Intel Core i7 14700KF / RAM: 32 GB / GPU: GeForce RTX 5060 Ti（VRAM 16 GB） Python: 3.13 / 主要ライブラリ: ollama pandas streamlit 評価データ: ローカルにキャッシュした大田区 2DK/2LDK の物件情報 30 件（全実験で固定） 最初は、VRAM 16 GB に余裕で収まる軽量モデル gemma4:e4b （9.6 GB）から試したのですが、賃料予測の手前の簡単な質問でつまづきました。試しに「大田区で有名な駅を 1 つ教えて」と聞いてみたところ、 gemma4:e4b は自信満々にこう答えました。 大田区で特に有名な駅の一つは、大田駅（おおたえき）です。 （中略）東急大井町線などが乗り入れており、大田区の主要な交通結節点の一つとなっています。 その他、エリアの特性によっては、新大田駅なども利用される大きな駅です。 「大田駅」も「新大田駅」も、実在しません。しかも、その架空の駅に「東急大井町線が乗り入れる交通結節点」というもっともらしい乗り入れ情報まで添えています。典型的なハルシネーションですね。地名すらこの調子では、複雑なスペックから経済価値を判断させるのは到底無理だということで、軽量モデルは早々に候補から外れました。 同じ質問を、ひとつ上の gemma4:26b に投げると、答えが変わります。 大田区で最も有名な駅といえば、蒲田駅（かまたえき）です。 大田区の最大のターミナル駅であり、JR、京急、東急といった複数の路線が乗り入れる交通の要所です。 概ね意図どおりの回答が得られました。 最低限の精度を求めるには、 26b が要るようです。 gemma4:26b は「蒲田駅」と正答。乗り入れ路線も正確な回答になっている。 ところが、 gemma4:26b を手元の RTX 5060 Ti で動かそうとして、最初の壁にぶつかります。 gemma4:26b は 4-bit 量子化でも約 17 GB あり、VRAM 16 GB にわずかに収まりません。Ollama は収まらない分（約 35 %）を RAM 側に退避させ、その部分を CPU で計算します。結果、GPU と CPU を行き来する構成になり、計算時間が大幅に増えてしまいました。 ここで重要なのは、 VRAM 不足が線形の劣化ではなく崖 だということです。 理由は、LLM の推論がメモリ帯域に律速されるからです。推論の中身は、膨大な重みをメモリから読み出して計算する処理の繰り返しで、ボトルネックは計算量よりも読み出しの速さにあります。GPU の VRAM はこの読み出しが桁違いに速い一方、CPU 側へ退避した層は、それよりずっと帯域の狭いシステム RAM を経由します。 約 17GB のモデルが 16GB の VRAM に収まらず、Ollamaによって自動的にモデルの 約 35% が RAM/CPU へ退避する結果に。処理速度は VRAM 容量を超えた瞬間に崖のように急落する 私の PC のスペックはごくごく一般的なゲーミング用ですので、 ローカル LLM を前提とした十分な VRAM を積んだ GPU でないとまともな推論能力は得られない というのが 2026 年 6 月時点の現在地となりそうです。 が、さすがにこの結果では終われないので、急遽 Google AI Studio から Gemma 4 の API を叩く形に切り替えました。これにより、Google 側が用意した計算資源を借りて、Gemma 4の26Bと31Bという大きめのモデルを（無料で）動かすことができます。一旦手元のハードの制約を外し、モデルそのものの実力を見にいきました。 結果と考察 — Gemma 4 vs Gemini 評価 30 件での実測をまとめます。ベースライン（線形回帰）は MAE 2.826 / MAPE 19.62 % / バイアス +0.092 でした。 モデル 実行環境 時間 コスト MAE MAPE バイアス 線形回帰ベースライン — — — 2.826 19.62% +0.092 Gemini 2.5 Flash-Lite API・並列×8 10.6 秒 2.10 円 3.177 17.42% −2.203 Gemini 2.5 Flash-Lite API・直列 64.9 秒 2.15 円 3.127 17.28% −2.167 Gemini 3.5 Flash API・並列×4 93.6 秒 29.61 円 3.157 17.11% −2.283 Gemini 3.5 Flash API・直列 約 5.3 分 28.97 円 3.340 18.24% −2.367 Gemma 4 31B Dense AI Studio・直列 約 27 分 0 円 3.317 18.25% −2.39 Gemma 4 26B a4b AI Studio・直列 約 1.4 時間 0 円 3.213 17.58% −2.24 Gemma 4 26B ローカル・直列 約 10.9 時間 118.21 円 11.566 71.14% −6.604 同じ 30 件でも、実行環境によって所要時間は大きな差になる。最速のクラウド並列と最遅のローカル直列の開きは、約 3,700 倍 比較対象とするクラウドLLMは、 Google 系列のモデルでそろえました 。先述の通り、Gemma 4 は Gemini と同じ研究基盤から生まれたモデルなので、ある程度公平な比較と言えるでしょう。選んだのは次の 2 つです。 Gemini 2.5 Flash-Lite （軽量クラウドモデル） — Gemma 4 とベンチマーク帯がほど近く、「同じくらいの賢さなら、ローカルとクラウドのどちらが割に合うか」というコスト対効果と、ローカルの代替になりうるかを見る役です。 Gemini 3.5 Flash （最新ハイエンド） — つい先日、2026 年 5 月 19 日の Google I/O 2026 で GA になったばかり。「コストをかけて上位モデルにすれば、差は埋まるのか」という上限を確認する役です。世代の 3.1 Pro 比で大半のベンチマークを上回りながら、 価格は約 25 % 安く、出力は約 4 倍速い とされています。並列4件になっているのは1分あたりのレート制限がGemini 2.5 Flash Liteよりも厳しいため。 考察を 3 点 挙げます。 まず、 Ollamaローカル実行は、実行時間もコストも突出して重い。 同じ 30 件に対して、Gemini 2.5 Flash-Lite は並列で 10.6 秒・約 2 円。ローカルの 26B は約 10.9 時間・118.21 円。速度で約 3,700 倍、コストで約 60 倍の差です。VRAM溢れが発生するような欲張りなモデル選定を行った場合、という枕詞はつきますが、「追加コストは電気代だけだから安い」という直感には反する結果となりました。 一方で、これは「VRAM に収まらなかったとき」の数字でもあります。仮に RTX 4090（VRAM 24 GB）のように、 gemma4:26b （約 17 GB）がまるごと載る GPU だったらどうでしょう。ここでは、AI Studio 版の 26B と同じ約 1.4 時間で終わると仮定して、電気代を試算します。 計算式は 消費電力(kW) × 時間(h) × 31 円/kWh （東京電力 従量電灯B 第2段階）です。時間を 1.4 時間に固定し、消費電力の前提だけを 3 通り変えてみると、以下の表のようになります。 消費電力（PC 全体の目安） 計算式 30 件の電気代 350 W（本実験のローカル機と同じ前提） 0.35 × 1.4 × 31 約 15 円 450 W（RTX 4090 の TDP＝GPU 単体ピーク） 0.45 × 1.4 × 31 約 20 円 600 W（4090 を積んだ PC 全体の高負荷時） 0.60 × 1.4 × 31 約 26 円 RAM 退避したケースに対して、4 分の 1 以下にとどまります。しかも 1.4 時間はクラウド側の所要時間で、フル GPU ならさらに速く・安くなる可能性が高い。とはいえ、Gemini 2.5 Flash-Lite が 2.1 円に収まることを鑑みると、 「ローカル LLM は電気代だけだから安い＝APIコストをGPU投資によって回収できる」という神話は完全に否定された と言えるでしょう。 同じ 30 件を Gemini 2.5 Flash-Lite の並列実行で処理した結果。所要時間は 10.6 秒 ふたつ目。 どの LLM も、面積と徒歩だけの線形回帰（MAE 2.826）に、MAE で勝てていません。 何十億ものパラメータを持つ最新モデルが、2 変数のごく単純な式に及びませんでした。 一方で、指標MAPEを変えると景色は反転します。率で見る MAPE では、LLM 群はそろって 17 % 台に収まり、ベースラインの 19.62 % を下回りました。 平均誤差では負け、率で見れば勝っている。 MAE は高額物件の絶対誤差に引っ張られ、MAPE は安い物件の外れも対等に扱います。どちらの物差しを採るかで、勝者がそのまま入れ替わるわけです。これは、「どの指標で測るか」を決めることが、結論そのものを決めてしまう、という実務的な教訓ですね。 MAE で負けた理由はおそらく、賃料というタスクがそもそも面積に対してほぼ線形で、「避けられない複雑さ」が低いからでしょう。タスクが単純なとき、単純なモデルが分散の大半を説明してしまいます。そこに LLM を持ち込むと、かえってノイズを上乗せする結果に終わってしまいます。 最後に、 最新・高価なモデルほど効く、とは限らないことが浮き彫りになりました。 Gemini 3.5 Flash は、Gemini 2.5 Flash-Lite 比約 14 倍のコスト（約 30 円）をかけて、精度はほぼ横ばいでした。少なくともこの物件タスクでは、価格に見合う上積みは得られなかった、ということです。 肝心の良コスパ物件判定ですが、コスパスコア（実賃料 ÷ 予測相場）が 0.85 を下回る物件を「お買い得」として抽出したところ、安定して動いたモデルはどれもほぼ同じ顔ぶれを拾いました。筆頭は JR 京浜東北線・蒲田駅 徒歩 4 分の 2DK（実賃料 8.5 万円／予測相場 11.2 万円＝スコア約 0.76）で、これに鵜の木・パレスフロラシオンの 2DK が続き、お買い得はおおむね 3 件前後でした。もちろん今回取り扱った物件のスペックは限定的ですので詳細を吟味する必要はありますが、第一層の捌きとしては十分に絞り込めているのではないでしょうか。引っ越しを検討している同僚に試してもらってFBをもらっていけば、案外実用的なアプリとして運用できるかもしれません。 現在地の見立てと展望 実験を踏まえ、ローカル LLM の現在地の見立てを述べます。 現時点での結論として、実用的なのは Google AI Studio から Gemma 4 を叩く 形でしょう。学習利用という枷こそあれど、無料で使え、Google 側の計算資源を用いて大きめのモデルも問題なく動きます。少なくとも、家庭用 GPU で 17 GB 級のモデルと格闘するよりは、ずっと現実的な選択肢でしょう。ただし、 この無料枠がいつまで続くかは分かりません 。AI企業は投資を回収するフェーズに入っており、利益にならない計算資源をどこまで無料で使わせてもらえるかは完全にGoogle側の経営判断に委ねられています。 次点は Gemini 2.5 Flash Lite などの軽量・高速モデル を用いる ことでしょう（この記事の執筆中に EOL が発表されてしまいましたが……移行先は Gemini 3.1 flash Lite ですかね）。Gemma 4 は、Gemini 2.5 Flash-Lite のような軽量・高速なクラウドLLMと比べて、推論力では一段劣る印象でした。費用対効果を考えると、軽量なクラウドLLMは安くてリターンの大きい投資であると考えます。少なくとも私ならこの選択肢を選ぶでしょう。 繰り返しになりますが、今回の検証はローカルLLMの「現在地を探る」ことを目的としています。ビッグテックによるLLMの開発競争は、さながら米露の宇宙開発の様相。ローカルLLMについても、量子化や知識蒸留技術の進歩によって（なんならムーアの法則的な計算資源面の改良にも期待しつつ）、さらなる軽量化・ベンチマークスコア向上が期待されます。特に今回題材に挙げた Gemma 4 については Gooole がかなり意欲的に開発を進めているので、今後とも注視していきたいです 今後の課題としては、本命のタスクである株式投資エージェントによるベンチマークでしょうか。今回、最新の Gemini 3.5 Flash も同じ土俵で回しましたが、賃貸予測タスクでは割高なだけで、明確な上積みはありませんでした。ただ、3.5 Flash の本領は、エージェントや金融まわりの複雑なタスクにあるとされています（金融エージェント向けのベンチマーク（ Finance Agent v2 ）では、前世代の Gemini 3.1 Pro を大きく上回ったと報告されています）。だとすれば、その差が出るのは今回のような単純な題材ではなく、株式投資エージェントのような複雑な経済価値判断を要するシーンのはずです。時間を見つけて本来の戦場できちんと測っていきたいです。 おわりに 24 時間 365 日稼働し続ける「眠らない部下」には、電気代という無視できない額の請求書がついてまわります。1 kWh あたり 31 円のこの国で GPU を本気で減価償却しきろうと考えたとき、行き着く先はソーラーパネルを導入することしかないかもしれませんね。 データを手元に、計算を手元に、最後は電力まで手元に。ローカル化の旅は、案外その先まで続いているのかも……。 2026/06/04追記 なんて話をしていたら、Googleが「Gemma 4 12B」をリリースしましたね。今回のモデルは VRAM 16 GBで動く というところがプッシュされているようです。AI開発戦争は秒進分歩。ローカルLLMの 「本当の現在地」 については、ぜひ皆さんのほうで検証いただけますと助かります。 なんて間の悪い！！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @kikuchi.s レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

本記事は 2026 年 6 月 2 日に公開された “ Announcing durability for Amazon ElastiCache for Valkey ” を翻訳したものです。 Amazon ElastiCache は数十万のお客様にサービスを提供し、Valkey、Memcached、Redis OSS のワークロード全体で毎秒数十億のリクエストをマイクロ秒のレイテンシーで処理しています。多くの組織では、ElastiCache のマルチ AZ レプリケーションと自動フェイルオーバーがレジリエンスの要件を満たしていますが、お客様がキャッシュだけでなく永続的なデータストアとして ElastiCache を採用するケースが増えるにつれ、データ損失が主要な懸念事項となっています。 本日、 Amazon ElastiCache for Valkey の耐久性機能の提供開始を発表します。これにより、データ損失を許容できないワークロードに ElastiCache を使用できるようになります。 この記事では、耐久性がどのように機能するかを説明し、アーキテクチャを詳しく見ていき、耐久性が ElastiCache でお客様が期待するマイクロ秒単位のレイテンシーを損なわないことを示すパフォーマンス結果を共有します。 耐久性の仕組み ElastiCache の耐久性は、マルチ AZ トランザクションログを使用して、インフラストラクチャ障害時の高速リカバリと再起動によるデータ保護を提供します。ElastiCache は 2 つの耐久性オプションを提供しています。ゼロデータ損失を設計した同期書き込みと、マイクロ秒単位の書き込みレイテンシーを実現する非同期書き込みです。 同期書き込み は、データ損失が許容できない場合に適した選択肢です。ElastiCache は、クライアントに応答する前に、マルチ AZ トランザクションログ内の少なくとも 2 つのアベイラビリティーゾーン (AZ) にデータを永続化します。確認応答された書き込みはすべて永続的であり、書き込みレイテンシーは 1 桁台のミリ秒です。プライマリノードは強い整合性を持ち、プライマリでの読み取り操作は常に最新のデータを返します。この整合性はフェイルオーバー時にも保持されます。同期書き込みは、RAG アプリケーション向けのナレッジベース、AI エージェントの長期メモリ、AI エージェントのワークフロー状態、決済トークン化、ストリーミングメタデータ、ゲームプレイヤーの状態、リアルタイム在庫管理など、書き込みの損失が誤ったアプリケーション動作を引き起こす場合に最適です。 非同期書き込み は、データが復旧可能であるものの、ソースからの再構築が遅い、または運用コストが高い場合に適した選択肢です。非同期書き込みでは、クライアントへの応答後にデータが Multi-AZ トランザクションログに永続化されるため、追加コストなしでマイクロ秒単位の書き込みレイテンシーを維持できます。万が一障害が発生した場合、最大 10 秒間のコミットされていないデータが失われる可能性があります。潜在的なデータ損失を制限するため、ElastiCache は耐久性ラグを監視します。これは、まだログに永続化されていない最も古い書き込みからの経過時間です。このラグが 10 秒に達すると、プライマリノードはログが追いつくまで書き込みの受け入れを停止します。非同期書き込みは、セッションストア、ゲームのリーダーボード、リアルタイム分析、事前ロードされたデータセットなど、数秒間の最近の書き込みを失うことは許容できるものの、より大きなギャップが生じると調整にコストがかかる場合に最適です。 耐久性を有効にしていない ElastiCache は、データがオンデマンドで簡単に再構築できる場合に適しています。元となるデータベースに基づくリードスルーキャッシュ、レート制限カウンター、または欠落したエントリをその場で取得または再計算できるワークロードに使用してください。 同期書き込みと非同期書き込みの両方で、マイクロ秒単位の読み取りレイテンシーが維持されます。いずれのオプションでも、レプリカノードは結果整合性を持ち、レプリカからの読み取り操作は常に最新の書き込みを反映するとは限りません。次の表に、2 つの耐久性オプションをまとめます。   同期書き込み 非同期書き込み 標準的な読み取りレイテンシー マイクロ秒 マイクロ秒 標準的な書き込みレイテンシー 1 桁ミリ秒 マイクロ秒 データ損失に関する保証 データ損失ゼロ。確認された書き込みはすべて、少なくとも 2 つのアベイラビリティーゾーンにわたって永続化されます 万が一障害が発生した場合、最大 10 秒間の確認された書き込みが失われる可能性があります。 一般的なユースケース RAG アプリケーションのナレッジベース、AI エージェントの長期メモリとワークフロー状態、支払いトークン化、リアルタイム在庫管理 セッションストア、ゲームリーダーボード、リアルタイム分析、事前ロード済みデータセット アーキテクチャ 次の図は、Multi-AZ のトランザクションログを使用した ElastiCache の耐久性がどのように機能するかを示しています。 同期書き込み 同期書き込みが設定されたクラスターにクライアントが書き込みコマンドを送信した場合: プライマリノードがメモリ内で書き込みコマンドを受信して実行します。 書き込みは、少なくとも 2 つのアベイラビリティゾーンにまたがる Multi-AZ トランザクションログに永続化されます。 永続化が確認されると、プライマリはクライアントに成功レスポンスを返します。 これは、クライアントが成功レスポンスを受け取った後、その書き込みが永続化されることを意味します。プライマリノードがその直後に障害を起こしても書き込みは失われず、新しいプライマリへのフェイルオーバー後を含め、プライマリからの今後のすべての読み取りにその書き込みが反映されます。トレードオフは書き込みレイテンシーです。各書き込みはトランザクションログへの AZ 間ネットワークラウンドトリップが発生するため、数ミリ秒の書き込みレイテンシーが生じます。 非同期書き込み 非同期書き込みが設定されたクラスターにクライアントが書き込みコマンドを送信する場合： プライマリノードがメモリ内で書き込みコマンドを受信して実行します。 プライマリはマイクロ秒のレイテンシーで即座にクライアントに応答を返します。 バックグラウンドで、書き込みは Multi-AZ トランザクションログに書き込まれます。 クライアントが成功レスポンスを受信した時点では、書き込みはプライマリノードのメモリ内にのみ存在します。まだトランザクションログには書き込まれていません。書き込みが永続化される前にプライマリノードに障害が発生すると、その書き込みは失われます。これが非同期書き込みの基本的なトレードオフです。マイクロ秒単位の書き込みレイテンシーと引き換えに、データ損失が発生しうる限られた時間枠が存在します。 非同期書き込みの耐久性バッファ 非同期書き込みによる潜在的なデータ損失を制限するため、ElastiCache は最大 10 秒の耐久性バッファを強制します。プライマリノードは、受け入れられたがまだ Multi-AZ トランザクションログに永続化されていない最も古い書き込みの経過時間を継続的に追跡し、この値を DurabilityLag メトリクスとして Amazon CloudWatch に公開します。 この経過時間が 10 秒未満である限り、ノードは通常通り新しい書き込みを受け入れ続けます。バッファが 10 秒を超えて増加した場合、例えばトランザクションログへの一時的なネットワーク輻輳が原因である場合、プライマリは追いつくまで一時的に受信する書き込みコマンドを拒否します。この期間中も読み取り操作はマイクロ秒のレイテンシーで提供され続けます。トランザクションログが追いつき、耐久性ラグがしきい値を下回ると、手動介入を必要とせず書き込みが自動的に再開されます。実際には、ほとんどの書き込みは 10 秒のしきい値内に十分永続化され、ほとんどのクラスターは通常の動作条件下で拒否状態に入ることはありません。非同期耐久性クラスターにトラフィックを送信するようにクライアントを構成する場合、一時的に拒否された書き込みコマンドに対して指数バックオフによる自動リトライを有効にすることをお勧めします。Valkey の公式オープンソースクライアントライブラリの 1 つである Valkey GLIDE をお勧めします。これは信頼性と高可用性を考慮して設計されています。GLIDE は指数バックオフによる自動リトライとアベイラビリティーゾーン認識ルーティングをサポートしています。クライアント構成のベストプラクティスについては、 Best practices: Valkey/Redis OSS clients and Amazon ElastiCache を参照してください。 障害シナリオ ElastiCache の耐久性は、以下の障害タイプから保護します。 プライマリノードの障害。 プライマリノードに障害が発生した場合、ElastiCache は自動的にレプリカへのフェイルオーバーをトリガーします。レプリカはトランザクションログから追いつき、その後新しいプライマリとして書き込みを受け入れ始めます。障害が発生したノードは置き換えられ、ログから同期されます。同期書き込みでは、データは失われません。非同期書き込みでは、プライマリが障害を起こす前にトランザクションログにすべての書き込みが記録されていない可能性があるため、最大 10 秒間の確認応答済みの書き込みが失われる可能性があります。 リードレプリカの障害。 リードレプリカに障害が発生した場合、障害が発生したノードは置き換えられ、選択された耐久性オプションに関係なく、Multi-AZ トランザクションログから同期されます。データ損失は発生しません。 シャード全体の障害 (シャード内のすべてのノード)。 シャード全体に障害が発生した場合、すべてのノードが置き換えられ、Multi-AZ トランザクションログから同期されます。同期書き込みでは、データは失われません。非同期書き込みでは、最大 10 秒間の確認応答済みの書き込みが失われる可能性があります。コミットされたデータが復元された後、置き換えられたノードの 1 つが自動的に新しいプライマリとして選出されます。 パフォーマンス分析 ElastiCache の耐久性を有効にした場合と無効にした場合のスループットと読み取り/書き込みレイテンシーを測定し、それらを比較しました。その結果、ElastiCache で耐久性を有効にしても、お客様が ElastiCache に期待するマイクロ秒単位のレイテンシーが損なわれないことを実証しました。 テスト方法 r7g.4xlarge ノードを使用して、耐久性なし、同期書き込み、非同期書き込みの Valkey 9.0 for Amazon ElastiCache クラスターを起動しました。各クラスターは、1 つのプライマリノードと 1 つのリードレプリカで構成され、テスト実行前にサンプルデータが事前に投入しました。Valkey のデフォルトのパフォーマンス測定ツール ( valkey-benchmark ) を使用して、300 万個のキーでコマンドパイプラインなしで実行し、プライマリノードと同じ AZ 内の 10 個の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使用してクラスターにトラフィックを向けました。一般的なお客様のワークロードパターンを代表する混合ワークロード (80% 読み取り、20% 書き込み) を使用して、50K と 100K TPS の 2 つのスループットレベルでテストしました。ElastiCache クラスターはマルチ AZ 分散システムであるため、同一のセットアップでも下の表の数値からある程度のばらつきが観察される場合があります。 次の表は、r7g.4xlarge ノードにおけるすべての ElastiCache オプションの読み取りおよび書き込みレイテンシーを比較したものです。 ワークロード (80% 読み取り、20% 書き込み) ElastiCache オプション ノードタイプ 読み取り P50 読み取り P90 書き込み P50 書き込み P90 50K TPS 耐久性機能なしの ElastiCache r7g.4xlarge 260 µ s 301 µ s 147 µ s 185 µ s 50K TPS 非同期書き込み r7g.4xlarge 245 µ s 289 µ s 112 µ s 152 µ s 50K TPS 同期書き込み r7g.4xlarge 245 µ s 288 µ s 2.15 ms 2.36 ms 100K TPS 耐久性機能なしの ElastiCache r7g.4xlarge 263 µ s 301 µ s 160 µ s 196 µ s 100K TPS 非同期書き込み r7g.4xlarge 245 µ s 286 µ s 128 µ s 158 µ s 100K TPS 同期書き込み r7g.4xlarge 879 µ s 992 µ s 2.72 ms 3.12 ms 重要なポイント: すべてのオプションでマイクロ秒の読み取りレイテンシーを維持します。同期か非同期かに関わらず、耐久性は両方のスループットレベルでマイクロ秒の読み取りパフォーマンスを維持するため、実際のユースケースの大半を占める読み取り中心のワークロードに適しています。 非同期書き込みは、耐久性を有効にしていない ElastiCache と同等のレイテンシーを実現します。50K TPS と 100K TPS の両方で、読み取りと書き込みのレイテンシーはいずれもマイクロ秒レベルです。追加料金なしで耐久性を追加でき、一般的なワークロードレベルでのスループットへの影響はごくわずかです。データ損失ゼロを必要としないすべてのワークロードに対して、非同期書き込みをデフォルトとして推奨します。このオプションは、レイテンシーのペナルティなしで耐久性を提供します。 同期書き込みは、中程度のスループットでマイクロ秒の読み取りレイテンシーを維持します。50K TPS では、読み取りレイテンシーは 300 µ s 未満のままです。100K TPS では、システムがトランザクションログへのより高い並行性を処理するため、読み取りレイテンシーはサブミリ秒 (879 µ s) に増加します。書き込みレイテンシーは、両方のスループットレベルでミリ秒の 1 桁台に留まります。これは、書き込みを確認する前に 2 つのアベイラビリティーゾーンにデータを永続化するための予想されるトレードオフです。アプリケーションがデータ損失を一切許容できない場合は、同期書き込みを使用する必要があります。 ElastiCache の耐久性を使い始める 前提条件 始める前に、以下を確認してください。 アクティブな AWS アカウント AWS CLI バージョン 2.x 以降がインストールおよび設定されていること elasticache:CreateReplicationGroup と elasticache:ModifyReplicationGroup の IAM 権限 永続化クラスターの作成 耐久性を使い始めるには、新しい ElastiCache クラスターを作成し、 AWS Management Console 、AWS Software Development Kit (SDK)、または AWS Command Line Interface (CLI) を使用して、希望する耐久性オプションを選択する必要があります。 AWS マネジメントコンソールの使用 新しいクラスターを作成する際は、Valkey 9.0 以降を選択してください。クラスター設定で希望する耐久性オプションを選択します。 AWS CLI の使用 同期書き込みを使用する新しい耐久性のあるクラスターを作成するには： aws elasticache create-replication-group \ --replication-group-id my-durable-cluster \ --replication-group-description "ElastiCache durable cluster" \ --engine valkey --engine-version 9.0 \ --num-node-groups 2 --replicas-per-node-group 1 \ --cache-node-type cache.r7g.large \ --multi-az-enabled \ --transit-encryption-enabled \ --durability sync \ --region us-east-1 非同期書き込みを使用するクラスターを作成するには、 --durability async を設定します。 aws elasticache create-replication-group \ --replication-group-id my-durable-cluster \ --replication-group-description "ElastiCache durable cluster" \ --engine valkey --engine-version 9.0 \ --num-node-groups 2 --replicas-per-node-group 1 \ --cache-node-type cache.r7g.large \ --multi-az-enabled \ --transit-encryption-enabled \ --durability async \ --region us-east-1 クラスターの検証 クラスターを作成した後、耐久性が有効になっている状態で実行されていることを確認できます。 aws elasticache describe-replication-groups \ --replication-group-id my-durable-cluster \ --query 'ReplicationGroups[0].[Status,Durability]' --region us-east-1 出力には、ステータスが available として、選択した耐久性オプションが表示されるはずです。 耐久性オプションの切り替え 既存のクラスターを同期書き込みと非同期書き込みの間で切り替えるには、 modify-replication-group を使用します。 aws elasticache modify-replication-group \ --replication-group-id my-durable-cluster \ --durability async クリーンアップ 継続的な料金が発生しないように、作成した ElastiCache クラスターを削除してください。 aws elasticache delete-replication-group \ --replication-group-id my-durable-cluster \ --region us-east-1 注意: この操作により、クラスターとすべてのデータが永久に削除されます。続行する前に、必要なデータをバックアップしていることを確認してください。 まとめ ElastiCache の耐久性により、ElastiCache をキャッシングと永続的なデータストアの両方のユースケースで使用できます。同期書き込みは、マイクロ秒の読み取りレイテンシーと 1 桁ミリ秒の書き込みレイテンシーでデータ損失ゼロを実現するように設計されており、データ損失を許容できないワークロードに適しています。非同期書き込みは、追加料金なしで耐久性のない ElastiCache と同等のパフォーマンスを提供し、まれに障害が発生した場合に最大 10 秒の潜在的なデータ損失を許容できるワークロードに適しています。耐久性のない ElastiCache は、データをオリジンソースから再構築でき、書き込みの完全な可用性が最重要な従来のキャッシングワークロードに適した選択肢です。 ElastiCache の耐久性は、Valkey 9.0 から、すべての AWS 商用リージョン、AWS 中国リージョン、および AWS GovCloud (US) リージョンでご利用いただけます。料金の詳細については、 Amazon ElastiCache 料金ページ をご覧ください。詳細については、 ElastiCache ドキュメント をご覧ください。 著者について Jules Lasarte Jules は Amazon インメモリデータベースチームのソフトウェア開発エンジニアです。ElastiCache の耐久性に関するエンジニアリング活動を主導し、高性能分散システムとインメモリワークロードのデータ保護に注力しています。カナダのバンクーバーを拠点としています。 Karthik Konaparthi Karthik は Amazon インメモリデータベースチームのプリンシパルプロダクトマネージャーで、ワシントン州シアトルを拠点としています。データに関するあらゆることに情熱を持ち、お客様の課題を彼らが愛する製品に変えることを楽しんでいます。仕事以外では、家族と新しい場所を探索することを楽しみ、常に次の素晴らしいレストランを探しています。 本記事は、 Announcing durability for Amazon ElastiCache for Valkey を翻訳したものです。翻訳は Solutions Architect の Hayato Tsutsumi が担当しました。

ニフティ社内で従業員が使う社内メールや予定表、カレンダー。さらには、SlackやGoogle Workspaceといった外部ツールまで、数多くのプロダクトの運用を担うのが、プラットフォームチーム（以下、PFチーム）です。従業員を「ユーザー」と呼び、日々みんなが滞りなく業務を行えるよう、縁の下で支えています。 既存ツールの運用だけでなく、新規の外部サービスの導入検討や、時にはツールの開発までを担うというPFチーム。その詳しい業務内容や印象的だったプロジェクト、また、仕事のやりがいについて、メンバーに話を聞きました。 自己紹介 D.Kさん 2020年4月に新卒入社。業務内容はID基盤システム、コラボレーションツールの保守・運用。趣味はコーヒー。最近はハイカカオチョコにハマって自席に常備。 Y.Kさん 2019年4月に新卒入社。業務内容は社内システムの運用・保守・刷新。趣味は散歩と、温泉でゆっくりすること。 K.Gさん 2024年4月に新卒入社。業務内容は社内システムの運用・保守・刷新。趣味はゲーム、サッカー観戦、音楽を聴くこと。 「使えて当たり前」を担保しつつ、ユーザーの利便性を高めていく みなさんはニフティの「プラットフォームチーム（以下、PFチーム）」のメンバーということですが、具体的な業務内容を教えてください。 D.Kさん PFチームでは、ニフティの従業員（以下、ユーザー）が使う全ての社内システムの運用・保守・刷新を担っています。社内メールや予定表、カレンダーのほか、SlackやGoogle Workspaceなどの外部ツールまで、管理しているプロダクトは25程度。そのほか、他部署のシステムの管理のみを委託のような形で請け負ったりと、社内で使うツール関係については、大半を私たちのチームで取り扱っています。 具体的な仕事内容ですが、メインの業務は運用です。社内システムは「使えて当たり前」であり、トラブルが起こった瞬間に業務に支障が出てしまいます。ユーザーに滞りなく業務にあたってもらうため、問題が生じた場合でも影響を最小限に抑えながら運用する必要があります。 また、既存のツールの運用だけでなく、外部ツールの新しい機能を取り入れたり、新規サービスの導入を検討したりと、現在の水準は保ちつつユーザーさんがより便利に仕事ができるようサポートするのも、私たちの重要な業務ですね。 現在、PFチームは何名体制で業務にあたっていますか？ D.Kさん 現在は8名です。チームは大きくアカウント系、コラボレーションツール系に分かれていて、K.Gさんには主にアカウント系のプロダクトを、Y.Kさんは主にコラボレーションツール系のプロダクトを担当してもらっています。 では、それぞれご担当されている領域やプロダクトの詳細について、お二人からご説明いただけますか？ K.Gさん 私はアカウント系のチームで、主にユーザーのIDやパスワードの管理を担当しています。新たに入社された人が初出勤して仕事をスタートする前日までには、アカウントを付与して使える状態にしておかなければいけません。他にも、会社から支給されるパソコンのクラウド上での通信の管理や、セキュリティファイルの管理なども行なっています。後者で言うと、たとえばファイルのなかに個人情報が入っていないかをチェックするなど、幅広い業務がありますね。私はこの部署に来てまだ日が浅いのですが、かなり幅広い知識を求められる仕事だと感じています。 Y.Kさん 私はコラボレーションツール、分かりやすいところではSlackやGoogle Workspaceなどですが、その他にもさまざまな外部ツールをユーザーが「普通に使える状態」にするというのが大きな役割です。仮に不具合などがあって使用できない時に対応にあたったり、ユーザーからの問い合わせにも回答したりしています。 そうした運用以外に、「刷新」の役割も担っています。いま使用しているツールよりも便利なもの、新しいものが出てきた時に導入を検討したり、実際に置き換えを推進したりする仕事ですね。今もちょうど、RPAツールを別のものに置き換えるプロジェクトが動いています。 新しいツールに置き換える判断は、ある程度チームに委ねられているのでしょうか？ Y.Kさん そうですね。基本的にはプラットフォームチームのメンバーで検討し、上長のOKが出れば導入を推進できます。その後、セキュリティの要件を満たしているかどうかなどのチェックを経て、最終的に判断をするという流れですね。 ただ、もちろん刷新前のツールのほうが使い慣れていたり、愛着を持たれているユーザーもいるので、いきなりガラっと変えるのではなく、従業員と対話をして新しいツールの情報を伝えたり、利点をアピールしたりといったコミュニケーションは大事にしています。 外部サービスの利用から「自社開発」に切り替え、業務効率化を実現 これまでに担当したプロジェクトのなかで、特に印象深いものを教えてください。 Y.Kさん 私は、アルバイトや派遣社員用ID作成システムの刷新プロジェクトが印象に残っています。新しく入ったアルバイトの方の情報を入力するとアカウントが自動発行されるというシステムなのですが、もともとはかなり昔に外部のパートナー企業に作成してもらったもので、当時の仕様書も実際のソースコードも確認できないような状態。半ばブラックボックス化していたんです。 しかも、古いシステムなので頻繁にエラーが起こるような状態になっていて、その度にサーバーを再起動していたのですが、そうした運用を続けていくといつかシステム自体が使えなくなってしまう可能性もある。そこで、システム自体を刷新することになりました。 既存システムの運用だけでなく、そうした、いわば「古い遺産」を刷新するような業務もあるということですね。K.Gさんはいかがですか？ K.Gさん 私が担当した印象深いプロジェクトは、社内セキュリティレベル間のファイル移行ツールを刷新するというものです。もともとは外部提供を受けていたSaaSのシステムを社内で開発し直し、さらに改良を行いました。最も大きな改良点としては、それまではファイルを移行する際に、外部への不正なデータ持ち出しがないかどうかを目視でチェックしてから承認していたのですが、一部にAIを導入して自動で検知できるようにしたこと。いわゆる、DLPのシステムを導入しました。これにより、コスト削減とセキュリティレベルの向上につながり、ファイル移行ツールを使う業務の効率化につながったと思います。 そもそも、外部サービスから自社開発に切り替えた理由は何だったのでしょうか？ D.Kさん 一番は自社開発であれば、色んな機能を追加したり、使いやすくシステムを改良したりと、カスタマイズがしやすいことです。ファイル移行ツールに関しては、先ほどK.Gさんが言ったように、それまでのツールでは目視で一つひとつチェックしていたため、膨大な人的リソースが割かれていました。DLPを導入しようにも、既存のサービスの仕組みではなかなか組み込むことが難しい。また、DLP以外にも、今後ユーザーからの要望に応じてカスタマイズしやすいものにしたほうがいいだろうということで、自社開発に舵を切りました。 プラットフォームチームというと「既存システムをいかに滞りなく動かすか」がメインの業務というイメージですが、開発寄りのプロジェクトも結構あるのですね。 D.Kさん 最近はちょこちょこありますね。プラットフォームチームは企画から開発、さらには運用までを担うほか、レイヤーもインフラのサーバーからネットワーク、アプリケーションに至るまで、本当に「何でもやります」という感じのチームなので、活躍の幅が広い部署と言えるかもしれません。 ユーザーの「顔が見えること」が一番のやりがい みなさんは現在のプラットフォームチームの業務において、どんなところに楽しさ、やりがいを感じていますか？ Y.Kさん 一番はユーザーが社内という、最も身近な場所に存在していること。問い合わせに対して回答や解決をした時にも、すぐに「助かりました。ありがとうございます」と反応をもらえるのは嬉しいですし、やりがいにつながっていますね。 K.Gさん 私も似た答えになってしまいますが、ユーザーさんと直接やりとりできる点ですね。「こういう機能があるといい」といった要望も直で伝えてもらえるので、とても取り組み甲斐があると感じています。時には難しい要望もありますが、どれだけユーザーに寄り添えるか、実現に向けて努力できるかが自分の仕事だと考えていますので、そこはこれからも大事にしていきたいです。 ちなみに、K.Gさんは3人のなかでは最も若手ですが、プラットフォームチームのように色んなことができる現場だと、幅広い知見やスキルを獲得するという点でも大きいのではないでしょうか。 K.Gさん それはありますね。どちらかというとニフティには開発がメインのチームが多いと思います。そのなかで、システムの運用だったり、ユーザーさんと直接コミュニケーションできたりするのは貴重な機会。なおかつ、開発の案件もたまにあるので、おっしゃる通り色んな経験を積むことができるチームですね。 D.Kさん 私自身もわりと何でもやりたいタイプなので、今のチームはとてもフィットしていると感じます。あとは、二人が言ってくれたように、ユーザーと直に話ができるのは大きなやりがいにつながっていて。ユーザーと対話をして、トラブルシュートをして、その後のリアクションまでもらえる。そういう体験ができるチームって、ニフティのなかでもあまりないと思いますので、そこは大きな喜びですね。 後編に続きます！ 今回はニフティの社内プラットフォームチームのインタビュー（前編）の様子をお届けしました。 続きは近日公開予定の後編の記事をご覧ください。 このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報