開発スタッフがアプリ関連の最新技術やニュースをご紹介します。

最近、AIの進化で注目されているのが「AIエージェント」です。

これまでの生成AIは、質問に対して回答を返すことが中心でした。しかしAIエージェントは、目的を与えると、自分で情報を調べたり、ツールを操作したりしながら、ある程度自律的に作業を進めることができます。

便利になる一方で、AIに行動する権限を与えることで、新たなリスクも生まれています。

OpenAIで起きた「脱走事件」

2026年7月、OpenAIは社内で行っていたAIモデルの評価中に、AIモデルが隔離された評価環境から外部ネットワークへアクセスし、Hugging Faceのシステムに侵入した事例を公表しました。

AIモデルは、隔離された環境からインターネットへ接続するための経路を探しだし、未知の脆弱性を発見・悪用。最終的にはHugging Faceのシステムにアクセスし、評価問題の解答を得ようとしました。

つまり、「AIが勝手に外へ出た」というより、与えられた目的を達成するために、想定されていなかった手段まで自ら見つけて実行したことが、この事例の重要なポイントです。

AIエージェントは、単に回答するだけではなく、

・Webサイトを操作する
・ファイルを読み書きする
・プログラムを生成する
・プログラムを実行する
・外部サービスへアクセスする
・別のAIエージェントに作業を依頼する

といったことが可能です。

今回の事例では、こうしたAIの自律的な行動が、セキュリティ上の想定を超える結果につながりました。

これから重要になる「AIの安全対策」

AIエージェントを業務で利用する場合、単に「AIが正しい回答をするか」だけを確認するのでは不十分です。

例えば、
「AIが間違った判断や予想外の行動をした場合、どこまで被害が広がるのか？」
といった視点も必要になります。

そのため、
・AIに与える権限を必要最小限にする
・外部ネットワークへのアクセスを制限する
・AIの操作を監視・記録する
・重要な操作は人間の承認を必要とする
・問題が発生した場合に人間が停止できるようにする
といった仕組みも重要です。

「何をさせるか」だけでなく「何をさせないか」

今回の事例が示しているのは、AIの能力が高くなるほど、「AIに何をさせるか」だけでなく「AIに何をさせないか」も重要になります。

人間が一つひとつ操作する従来のAIとは違い、AIエージェントは複数の処理を連続して実行できます。

そのため、一つひとつの行動は小さなものであっても、それらが組み合わさることで、想定以上の結果につながる可能性があります。

木曜日担当：nishida

VRというと、ゴーグルのような大きな機器を頭に装着するイメージがあります。

高性能なVR機器では、ディスプレイだけでなく、プロセッサーやバッテリー、カメラ、センサーなども頭部に載せる必要があるため、どうしても本体が大きく、重くなっていました。

そんなVRの形が、これから大きく変わるかもしれません。

2026年9月に開催された「Meta Connect 2026」で、約100gという軽量なグラス型VRデバイス「Meta VR Glasses」が発表されました。

続きを読む: 約100gまで軽くなったVR――ヘッドセットは「メガネ型」へ向かう？

● 約100gのグラス型VR

Meta VR Glassesの大きな特徴は、その軽さです。

本体重量は約100gで、従来のVRヘッドセットと比べるとかなり軽量です。

ただし、VR機器全体が100gになったわけではありません。

グラス側にはディスプレイやカメラ、センサーなどを搭載し、演算処理を担当するプロセッサーやバッテリー、ストレージは別の「パック」に分離されています。

このパックをポケットやバッグなどに入れ、光ファイバーケーブルでグラスと接続する仕組みです。

重い部品を頭から下ろすことで、装着部分だけを軽くするという考え方です。

● 5Kのmicro-OLEDディスプレイを搭載

小型化しながら、表示性能も高くなっています。

Meta VR Glassesはmicro-OLEDを利用した「5K Infinite Display」を搭載し、37PPDの高精細表示に対応します。

映画や動画を見るだけでなく、仮想空間に複数のディスプレイを並べて作業するといった用途も想定されています。

VRというとゲームのイメージが強いですが、最近は仕事や映像視聴など、ゲーム以外の用途も広がりつつあります。

● コントローラーを持たずに操作

操作方法も従来のVRとは少し違います。

Meta VR Glassesでは、視線と手の動きを使って操作します。

対象を見て選択し、手を動かして操作するため、基本的には専用コントローラーを持つ必要がありません。

さらに、机やテーブルの表面を仮想的なキーボードやタッチパッドとして利用する機能も用意されています。

物理的なキーボードを持ち歩かなくても、大きな仮想画面と組み合わせて作業できる環境を目指しているようです。

● AIも操作の入口に

今回のVR GlassesにはAIエージェントも組み込まれます。

音声で質問したり、アプリを開いたり、必要な情報を検索したりといった操作をAI経由で行えるようになります。

最近はスマートグラスでもAIアシスタントの搭載が増えており、VRでも同じ流れが進んでいます。

今後は、アプリを探して操作するのではなく、「やりたいことをAIへ伝える」ことが操作の入口になっていくのかもしれません。

● Quest用アプリも利用可能

Meta VR Glassesは、Meta Questと同じ「Meta Horizon OS」を利用します。

そのため、これまでQuest向けに開発されてきたアプリやゲームを利用できることも特徴です。

新しいデバイスでは利用できるアプリの少なさが課題になりがちですが、既存のVRプラットフォームを利用することで、その問題を減らそうとしています。

● バッテリーは最大約3時間

軽量化の一方で、まだ課題もあります。

バッテリー駆動時間は、高解像度の映像を連続再生した場合で最大約3時間とされています。

また、グラス本体は軽いものの、演算用のパックを別に持ち歩く必要があります。

完全なワイヤレスではなく、グラスとパックがケーブルで接続されるため、この構成をどう感じるかは利用者によって分かれそうです。

● 価格は1,299.99ドル

Meta VR Glassesは2027年春に発売予定で、価格は1,299.99ドルと発表されています。

日本での販売価格は現時点では明らかになっていません。

かなり高価な製品になる可能性がありますが、従来のVRヘッドセットとは違う軽量設計が、どこまで装着感を改善できるのかは気になるところです。

● VRは「ヘッドセット」から「メガネ」へ？

最近は、翻訳やAIを重視するスマートグラス、映像表示を中心としたARグラスなど、メガネ型デバイスの種類が増えています。

今回のMeta VR Glassesは、本格的なVR体験までメガネ型に近づけようとする製品です。

これまで「スマートグラス」「ARグラス」「VRヘッドセット」はそれぞれ別の製品として存在していましたが、その境界は少しずつ曖昧になっているようにも感じます。

将来的には、普段は普通のメガネに近い形で利用し、必要なときだけ大画面やVR空間を表示する。

そんなデバイスが登場する可能性もありそうです。

Meta VR Glassesが実際にどこまで快適なのかは、2027年の発売を待つ必要があります。

それでも、VR機器の進化が単純な性能向上だけでなく、「どれだけ普通のメガネに近づけられるか」という段階に入ってきたことを感じさせる発表でした。

水曜担当：Tanaka

WindowsでWSL2＋Docker Desktopを使って開発していると、環境構築や起動時にちょっとした問題が発生することがあります。

今回は、実際に遭遇しやすい問題と、その対処方法を簡単にまとめます。

Dockerが起動しない

Cannot connect to the Docker daemon

と表示される場合は、まずDocker Desktopが起動しているか確認します。

それでもダメな場合は、Docker Desktopの

Settings → Resources → WSL Integration

を確認し、使用しているUbuntuが有効になっているか確認します。

WSLからDockerコマンドが使えない

WSLで、

docker ps

を実行してエラーになる場合は、Docker DesktopのWSL Integrationを確認します。

また、WSLを再起動すると解決することがあります。

wsl --shutdown

その後、Docker Desktopを再起動します。

Dockerの動作が遅い

WSL2＋DockerでLaravelなどの開発をしている場合、プロジェクトをWindows側に置いていると遅くなります。

例えば、

C:\Users\user\projects

ではなく、

/home/linux/projects

のようにWSL側にプロジェクトを置いて起動します

Windowsからは、

\\wsl.localhost\Ubuntu\home\linux\projects

でアクセスできます。

木曜日担当：nishida

ここ最近、自分のパソコン上で生成AIを動かす「ローカルAI」が急速に身近になってきました。

これまでは数十億～数百億パラメータ程度のモデルをPCで動かす例が中心でしたが、さらに大規模なAIモデルを一般的なハードウェアで利用するための技術も登場しています。

2026年8月17日に公開された研究「FreeToken」は、その一つです。

FreeTokenは、大規模なオープンウェイトAIモデルをデータセンターではなく、ノートPCやゲーミングPC、ワークステーションなどで動かすことを目的とした推論エンジンです。

研究チームの検証では、ゲーミングデスクトップで284B規模のモデル、さらにワークステーションでは753B規模のモデルを動作させたと報告されています。

● FreeTokenとは？

FreeTokenは、「Mixture of Experts（MoE）」と呼ばれる構造を持つAIモデルを効率よく実行するために開発されたソフトウェアです。

大規模なAIモデルは通常、大量のGPUメモリを必要とします。

そのため、数百B（数千億）パラメータ規模のモデルとなると、高価なGPUを複数搭載したサーバーやデータセンターで動かすことが一般的でした。

FreeTokenでは、GPUだけですべてを処理するのではなく、GPU、CPU、メインメモリ、PCI Expressなど、PCに搭載されている複数のリソースを組み合わせてAIモデルを実行します。

「GPUメモリにモデル全体が入らないなら使えない」という考え方ではなく、PC全体を一つのAI実行環境として扱うことが特徴です。

● MoEだから巨大モデルを動かしやすい

FreeTokenを理解するうえで重要なのが「MoE」という仕組みです。

一般的なAIモデルでは、入力を処理する際にモデル内の多くのパラメータを利用します。

一方、MoEではモデル内部に複数の「Expert」と呼ばれる処理部分を用意し、入力内容に応じて必要なExpertだけを選択して利用します。

例えば、モデル全体では数千億パラメータを持っていたとしても、1回の推論ですべてを同時に計算するとは限りません。

この特徴を利用し、必要なExpertを高速なGPUメモリへ配置し、それ以外をメインメモリ側へ置くことで、GPUメモリ容量を超える巨大モデルを扱いやすくします。

● CPUとGPUを状況に応じて使い分ける

巨大なAIモデルをPCで動かす方法としては、モデルの一部をGPUに置き、残りをCPU側のメモリへ逃がす「オフロード」が以前から利用されています。

ただし、CPUとGPUの間で頻繁にデータを転送すると、その通信速度がボトルネックになります。

FreeTokenでは、PCごとのCPU性能やメモリ帯域、GPU、PCI Expressの転送速度などを考慮しながら、どの処理をCPUで行い、どの処理をGPUへ送るかを動的に調整します。

単純に「GPUに入らないものをCPUへ移す」のではなく、そのPCでどの方法が速いのかを判断しながら処理する仕組みです。

同じAIモデルでも、搭載されているCPUやGPU、メモリ速度によって最適な実行方法は変わります。

FreeTokenは、こうしたPCごとの違いに合わせて処理方法を変えることを重視しています。

● 8GB GPUのノートPCでも利用を想定

研究では、さまざまな性能のPCでFreeTokenが検証されています。

対象には、GPUメモリ8GBのノートPCから、一般的なゲーミングデスクトップ、高性能なワークステーションまで含まれています。

論文では、8GB GPUを搭載したノートPCで35B規模のモデル、ゲーミングデスクトップでは284B規模のモデル、さらにワークステーションでは753B規模のGLM-5.2を実行できたと報告されています。

ただし、「モデルを読み込んで動かせる」ことと、「クラウドAIと同じ速度で快適に使える」ことは別の話です。

モデルの大きさや量子化方式、PCのメモリ容量、CPUとGPUの組み合わせなどによって、生成速度は大きく変わります。

そのため、「普通のPCですべての巨大AIが高速に動くようになった」と考えるのはまだ早そうです。

● AIエージェントを意識した仕組みも

FreeTokenは、単純なチャットだけでなく、AIエージェントでの利用も意識して設計されています。

最近のAIエージェントは、文章を生成するだけではありません。

• ソースコードを読む
• ファイルを編集する
• 外部ツールを呼び出す
• 実行結果を確認する
• 再び考えて次の操作を行う

といった処理を繰り返します。

このような使い方では、それまでの長い会話や処理内容を何度もAIへ読み込ませる必要があり、計算量も大きくなります。

FreeTokenでは過去の処理状態をキャッシュし、会話内容の一部が変わった場合でも、できるだけ同じ計算をやり直さない仕組みが導入されています。

ローカルAIを単なるチャットボットとしてではなく、「PC上で動くAIエージェント」として利用することも想定しているようです。

● CodexやClaude Codeなどとの接続も想定

FreeTokenは、OpenAI APIやAnthropic APIと互換性のあるインターフェースを提供しています。

そのため、対応するAIモデルをFreeTokenでローカル実行しながら、CodexやClaude Code、OpenCodeなどのAIコーディングツールから接続するといった使い方も想定されています。

普段使っているAIツールの操作方法はそのままに、実際の推論だけを自分のPCで行う環境を構築できる可能性があります。

ソースコードや社内データを外部のAIサービスへ送信したくない場合には、こうしたローカル環境が選択肢の一つになるかもしれません。

● 対応モデルは20種類以上

公開されているFreeTokenは、20種類以上のMoEモデルをサポートするとしています。

対応モデルには、Qwen系やDeepSeek系、GLM系など、大規模なオープンウェイトモデルが含まれています。

また、FP8やBF16だけでなく、NVFP4などモデルを小さく保持するための形式にも対応しています。

数百B規模のモデルを一般的なPCで扱うには、モデルそのものの容量を抑える技術も重要になります。

● 誰でもすぐ使えるわけではない

FreeTokenは興味深い技術ですが、現時点では注意点もあります。

現在公開されているCLI版の動作環境では、Linuxのx86_64環境とNVIDIA GPUが基本的な要件となっており、CUDA環境の準備も必要です。

また、大きなモデルを利用するには、GPUメモリだけではなく大量のメインメモリやモデルデータを保存するストレージも必要になります。

例えば「284BモデルがゲーミングPCで動く」という部分だけを見ると非常に手軽に感じますが、一般的なゲームを動かす場合とは必要なメモリ構成などが大きく異なる可能性があります。

さらに、今回紹介されている性能値はFreeTokenを開発した研究チーム自身による検証結果です。

今後、さまざまなPC構成で第三者による検証が進むことで、実際にどの程度実用的なのかがより分かってくるでしょう。

● 「VRAMの大きさ」だけで決まらないローカルAIへ

ローカルAIではこれまで、「どれだけ大容量のGPUメモリを搭載しているか」が非常に重要でした。

モデルがVRAMに入らなければ、CPU側へオフロードすることで大きく速度が低下することもありました。

FreeTokenが興味深いのは、その制約を単純に高価なGPUで解決するのではなく、CPU、GPU、メインメモリ、データ転送をまとめて最適化しようとしている点です。

最近は大規模なMoEモデルが次々と公開されていますが、モデルが公開されても、それを個人が実際に動かせなければローカルAIとして利用することはできません。

今後FreeTokenのような推論技術が発展すれば、「どれだけ大きなGPUを持っているか」だけではなく、「PC全体の性能をどれだけ効率よくAIに使えるか」が重要になっていくのかもしれません。

クラウドでしか利用できないと思われていた規模のAIモデルが、少しずつ個人のPCへ近づいてきています。

大規模AIを本当に日常的な速度で動かせるようになるのか、今後のローカルAI技術にも注目したいところです。

水曜担当：Tanaka

WSL2上でLaravelの開発環境をDockerで構築する場合、MySQLもDockerコンテナで動かす構成がよく使われます。

今回は、MySQLのポートを「3307」に変更した場合に、
WSL2側のLaravelとWindows側のDBeaverから接続する方法を紹介します。

Docker Composeの設定

compose.ymlを以下のようにします。

services:
app:
build: .
ports:

• “8080:80”
  depends_on:
• db

db:
image: mysql:8.0
environment:
MYSQL_DATABASE: laravel
MYSQL_USER: laravel
MYSQL_PASSWORD: password
MYSQL_ROOT_PASSWORD: root
ports:

• “3307:3306”

ここで重要なのが、

“3307:3306”

という設定です。

左側の「3307」がホスト側のポート、
右側の「3306」がMySQLコンテナ側のポートです。

つまり、

Windows / WSL2 → 3307 → MySQLコンテナ → 3306

という構成になります。

LaravelからMySQLへ接続

LaravelはWSL2のDockerコンテナ内で動作しているため、MySQLのサービス名「db」を指定します。

.env

DB_CONNECTION=mysql
DB_HOST=db
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=laravel
DB_PASSWORD=password

ここでDB_PORTを「3307」にしないのがポイントです。

LaravelとMySQLはDocker内で直接通信するため、
Laravelから見たMySQLのポートはコンテナ側の「3306」です。

Windows側のDBeaverから接続

Windows上で動作しているDBeaverから接続する場合は、
ホスト側に公開した「3307」を指定します。

DBeaverの設定例：

Host : localhost
Port : 3307
Database : laravel
Username : laravel
Password : password

DBeaverからは、

localhost:3307

に接続すると、DockerコンテナのMySQL「3306」へ接続されます。

まとめ

MySQLのポートを3307に変更した場合でも、
接続元によって指定するポートが異なります。

Laravel
→ DB_HOST=db
→ DB_PORT=3306

WindowsのDBeaver
→ Host=localhost
→ Port=3307

「3307:3306」の左側はホスト側、
右側はコンテナ側のポートです。

そのため、Dockerコンテナ間の通信では「3306」、
Windows側のDBeaverから接続するときは「3307」を指定します。

WSL2＋Docker環境でMySQLに接続できない場合は、
まず「どこからMySQLへ接続しているのか」と「ホスト側・コンテナ側のどちらのポートなのか」を確認すると、原因を切り分けやすくなります。

木曜日担当：nishida