ChatForge:Copilotキー用のローカルNPU AIアシスタント

公開日
2026年10月2日
更新日
2026年10月3日
著者
Jacob Lloyd — プロジェクト完了後、AIの支援を受けて執筆
読了時間
約18分で読めます

かんたんに言うと: 新しいIntel製のノートパソコンには、特別なAIチップ(NPU)が搭載されていますが、ほとんど使われていません。また、Microsoftのアシスタントを起動するための「Copilot」キーもあります。ChatForgeは無料のプログラムで、このキーに別の機能を割り当てます。つまり、アカウントや月額料金なしで、自分のノートパソコン上で動作するAIモデルから回答を得られる小さなチャットウィンドウが開くのです。天気やニュースなどの情報も検索可能です。より難しい質問に対しては、同じウィンドウからより大規模なAIサービスに問い合わせることもできます。

私のノートパソコンには専用のAIキーと専用のAIチップが搭載されていましたが、初期状態では両者は全く連携していませんでした。そのキーを押すとMicrosoft Copilotがクラウド上で起動するだけで、NPUは何もしていない状態でした。これが私にとっては本来あるべき以上に気になってしまったのです。そこで今では、そのキーを押すと私自身が作ったアシスタント「ChatForge」が起動するように設定しました。このアシスタントはIntel製の「AI Boost」NPU上で15億パラメータ規模のQwenモデルを実行しており、1秒間に42~51トークンを処理します。アカウントやサブスクリプションも不要で、トークンごとの課金もなく、会話内容は一切PC外に出ません。15億パラメータ規模のモデルでは対応しきれない質問が出た場合でも、同じポップアップ画面からワンクリックで私のGPUサーバーやクラウド上のモデルを利用できます。

この記事ではChatForgeの機能や、NPUとの付き合い方(コンパイルに成功したはずなのに意味不明な出力を返してしまったモデルの例も含め)、さらに小規模なモデルでも的確な回答を得られるための工夫などを詳しく紹介します。

要約

  • 概要:Windows 11向けの無料かつMITライセンスで配布されている通知領域用アシスタントです。Ctrl+Alt+C(またはPowerToysで再割り当てしたCopilotキー)を押すと画面右下に420×620ピクセルのポップアップが現れ、Escキーで閉じられます。ソースコードは github.com/LaserLloyd/ChatForge にあります。
  • ローカルモデル: Qwen2.5-1.5B-Instruct(INT4形式、ダウンロードサイズは0.94GB)がIntel製NPU上でOpenVINO Model Serverによって実行されます。初回ロード時には約45秒かけてNPU向けにコンパイルされ、その後はキャッシュから約3秒で読み込まれ、1秒間に42~51トークンを処理します。10分間何も操作がないと自動的にアンロードされます。
  • 大規模モデルも同様のメニューから利用可能: StudioForge(自身で用意したGPUサーバー)、MiniMax、OpenAI、DeepSeek、その他OpenAI互換のURLも選択できます。各APIキーはWindowsの資格情報マネージャーに保存され、設定ファイルには一切記録されません。
  • 9種類のツール: Web検索やニュース検索、ページ取得、天気予報、Wikipedia検索、為替レート、日時確認、電卓などがあります。また create_document 機能ではモデルが作成したWord・Excel・PowerPointファイルを保存できます。1回のメッセージにつき最大10個までファイルを添付して質問することも可能です。
  • 制限事項: エージェント機能はありません。ツールによってプログラムが実行されたり設定が変更されたりすることはなく、文書作成用のツールも自身のフォルダー内に新規ファイルを追加するだけです。

実際に得られるもの

どんなアプリケーションからでも質問できるようになります。キーを押して質問文を入力し、回答を確認したらEscキーで終了できます。各回答には使用されたモデル名と処理速度が記載されているため、無料のローカルモデルが使われたのか、課金対象となるクラウド上のモデルが使われたのかが常に判別可能です。リアルタイムな情報が必要な質問の場合はツールチャイムが表示され、大規模モデルによるレポート作成時には「開く」や「フォルダーで表示」ボタン付きの文書カードも返答に含まれます。

ダークテーマのChatForgeポップアップ。ヘッダーには『Local (NPU)』とQwenモデル名、準備完了を示すドットが表示されている。リスボンの天気に関する質問に対し、天気ツールチャイムとMarkdown形式の短い回答が示され、『Qwen2.5-1.5B-Instruct-int4-ov、47.6 tok/s』と記載されている。
NPU上で処理された天気に関する質問:返答の上にツールチャイムがあり、中に表も含まれている。
MiniMax-M3が選択された状態のポップアップ。ユーザーはスプレッドシートを添付して1ページ分のWordレポート作成を依頼した。返答にはcreate_documentツールチャイムと箇条書きの要約、そして保存された.docxファイル用の『開く』『フォルダーで表示』ボタン付き文書カードが示されている。
スプレッドシートを入力し、クラウド上のモデルによってWordレポートが出力された例。
空のチャット画面上に開かれたモデル選択メニュー。最後に使用したモデルが先頭に表示され、次いで『Local (NPU)』やMiniMaxといったプロバイダーグループが現れる。OpenAIやDeepSeekはキーが登録されていないため表示されていない。
モデル選択メニュー:直近で使用したモデルが最優先され、設定済みのプロバイダーのみがリストされる。

スクリーンショット内の会話内容、図表、場所、サーバー名などはすべて例示用データです。UI自体は実際のもので、Edge(WebView2の基盤となるエンジン)上でプロジェクトの開発用モックを使用して描画されています。

入手方法

MITライセンスで配布されているリポジトリが github.com/LaserLloyd/ChatForge です。この中には本記事で引用したNPU性能測定値などをまとめた ランタイムに関する注意事項 も含まれています。ZIPファイルを希望される場合は、本ページ末尾のダウンロードボックスやサイト内の ダウンロード ページからも入手可能です。

全体の仕組み

すべての処理は1つのPythonプロセスが管理します。タスクトレイアイコン、グローバルホットキー、ポップアップおよび設定ウィンドウ(WebView2上で動作するpywebviewを利用)や、回答のストリーム処理やツール実行を行うasyncioコアもこのプロセスが担当します。モデルサーバーはこのプロセスが完全に管理する子プロセスであり、ローカルモデル選択時のポップアップ開設時に起動し、アプリケーション終了時にはWindowsのジョブオブジェクト機能によって強制終了されるため、クラッシュが発生してもNPU上にモデルが残り続ける事態は起こりません。

実際、ほとんどの部分は一から作成されたものではありません。これを誇りに思っているのですが、プロセス管理機能やダウンローダー、タスクトレイアイコン、ログ記録機能などは StudioForge から流用しています。チャットUIやMarkdown処理パイプラインは DisPatch のものを利用し、ストリーム処理用クライアントも私が開発したベンチマークツールから拝借しています。これらすべては既に数か月間日常的に使用され、問題なく稼働している実績があり、各モジュールの先頭部分にもその事実が明記されています。こうした再利用が実現できたおかげで、最初のコミットとバージョン0.1.0の間隔はわずか2日(2026年9月30日夜から10月2日まで)となり、約1,000行からなる計画書に基づきLLMエージェントが全体の組み立てを実施しました。

インストール方法

リポジトリ内の docs/SETUP.md に詳細な手順が記載されていますが、簡単にはPowerShellコマンド3つとモデルのダウンロードだけで済みます。

git clone https://github.com/LaserLloyd/ChatForge.git
cd ChatForge
py -3.12 -m uv sync --extra dev

py -3.12 -m uv run chatforge runtime install   # OpenVINO Model Server 2026.4.0を139MB分ダウンロード、SHA-256値も指定済み
py -3.12 -m uv run chatforge doctor            # Python・WebView2・NPU・OVMS・キーリング・ディスク空き容量などをチェックし、パス/警告/失敗の一覧を表示

その後 launchers\ChatForge.bat を実行し、Settings > Models から Qwen で検索して Recommended と記載された行にある Download ボタンを押せば、0.94GBサイズの OpenVINO/Qwen2.5-1.5B-Instruct-int4-ov がダウンロードされます。初回起動時にはログイン時自動起動設定(ユーザーごとのタスクスケジューラー登録で、管理者権限は一切不要)が有効化され、ホットキーの登録も行われます。最初のモデルロード時にはNPU向けコンパイル処理が約45秒間実施され、ポップアップヘッダーにカウントダウン表示があるため動作不能に見えることはありません。その後の起動ではキャッシュから約3秒で読み込まれます。

Copilotキーの問題点

ノートパソコンを購入する際に誰も教えてくれない点があります。Copilotキーというのは、ユーザーが任意の機能に割り当てられるようなキーではありません。このキーを押すとWin+Shift+F23が送信され、Windows側でその組み合わせが内部処理用に登録されています。また、公式な設定画面ではあらかじめパッケージ化され署名済みのアプリケーションしか選択できません。つまり、自分で作成したプログラムはこのキーの利用対象外なのです。

実用的な解決策としては、PowerToysの「キーボードマネージャー」機能を利用する方法があります。ショートカットWin(左)+ Shift(左)+ F23をCtrl+Alt+C(ChatForge用のホットキー)に再割り当てし、PowerToysの「起動時に実行」オプションも有効にします。こうすることで、マイクロソフトがCopilot用に確保したこのキーが、代わりに自分のアシスタントを起動するようになります。万が一このキーが再びWindows検索やCopilotを呼び出してしまう場合は、PowerToysが実行されていない状態だということです。これが唯一の不具合パターンであり、実際に頻繁に起こるため、トラブルシューティングの最初に挙げられています。

15億パラメータモデルを実用可能にする工夫

15億パラメータ規模で、コンテキストウィンドウが4096トークンしかないモデルというのは、図書館の利用券を持った金魚にも似ています。ChatForgeにおける興味深い技術的工夫は、この制約を無視するのではなく、それと共存する形で設計されています。

  • ツールリストを短くする。 全9種類のツールが存在しますが、ローカルモデル向けには5つだけが提供されます(検索、ページ取得、天気情報、日付・時刻、計算機)。小規模なモデルは長いツールリストに混乱しやすいため、このように絞ることでツール呼び出しがスムーズになります。
  • 事前に調べておく。 「天気」「最新情報」「価格」など、リアルタイムなデータが必要な質問の場合、モデルが回答を生成する前に先に該当ツールが実行されます。その結果を基にモデルが回答するため、推測する必要がなくなります。これは単純なパターンマッチングであり、追加のモデル呼び出しも不要です。
  • 拒否反応の修正。 小規模モデルは検索ツールが利用可能でも「リアルタイムデータにアクセスできません」と答えてしまう傾向があります。第一人称で拒否する返答や、「調べてみます…」と言いながら実際には調べないケースも無視され、エンジン側が自動的に検索を行い、モデルに再回答させます。この間はポップアップに「調査中です…」と表示されるため、最初の不適切な返答を見ることはありません。
  • 要約処理を行わない。 会話内容がコンテキストウィンドウを超えた場合、古い発言部分はプロンプトから除外されます。ポップアップ内にはその境界を示す分割線も表示されます。裏で要約が行われることもなく、余分なモデル呼び出しも発生しません。またモデル側にも「古いメッセージは切り捨てられた」と伝えるため、勝手に内容を補完するような事態も防げます。
  • ループ防止機能と利用制限。 一つのメッセージに対して最大6回までしかツール呼び出しが許可されず、同じ処理の繰り返しも拒否されます。15億パラメータモデルであっても、放置すれば天気情報を永遠に問い続ける可能性があるためです。
  • 安全対策としてのバックアップ。 NPUモデルの読み込み失敗やクラッシュ、タイムアウトが発生した場合、同じメッセージをユーザーが指定した別のプロバイダーへ再送信することも可能です。

これらすべてはNPUを前提としていません。同じエンジンが大規模モデルにも対応しています。こうした工夫により、無料のローカルモデルでも「今週末は雨が降るか」といった質問に正しく答えられ、しかもNPUの性能を最大限に活かせるのです。

コンパイルは成功したが、全く使い物にならないモデル

当初はローカルモデルとしてQwen3-4Bを採用する予定でした。より大規模で新しいシリーズということで自然な選択肢でした。しかしリポジトリ内のdocs/RUNTIME-NOTES.mdによると、問題が発生しました。Qwen3-4B-int4-ovはNPU向けに何のエラーもなくコンパイルされますが、OVMS 2026.4では全く意味のない出力しか生成しません。一方で同じモデルファイルをCPU上で動作させると24トークン/秒という速度で正しい回答が得られます。この不具合はNPU特有のもので、あらゆるNPU設定を試しても同様の結果でした。またOVMS 2026.4ではツール呼び出しに対応しない量子化モデルしか存在しません。つまりNPU上では「コンパイルが成功した」だけでは何の保証にもならないのです。出力内容を確認せずに信頼してはいけません。

結局採用されたのはCore Ultra 5 226V(Lunar Lake)上で計測した以下の性能を持つモデルです:

Qwen2.5-1.5B-Instruct INT4 on the NPU 測定値
初回コンパイル(一回限り) 44.5秒
コンパイルキャッシュからの読み込み 2.7~3.2秒
デコード速度 42~51トークン/秒
短いプロンプトにおける最初のトークン到着までの時間 0.5~0.8秒
ディスク上のコンパイルキャッシュサイズ 306MiB
プロンプトウィンドウの上限 4096トークン

同じファイルには次のような調整ヒントも記載されています。OVMSではBEST_PERFというコンパイルフラグを指定すると、135秒もの時間がかかるもののデコード速度が約10%向上し48.3トークン/秒まで上がります。ChatForgeではこの設定は無効化されており、私もこれで正しいと考えています。45秒という初回の待ち時間は、ユーザーが「動作しない」と判断する限界値に近いからです。

ファイルを入力し、文書を出力

メッセージごとに最大10個までのファイルを添付可能です(クリップアイコン、ドラッグ&ドロップ、またはペーストで。各20MBまで)。コードやテキスト、CSV、JSON、HTML、Word、Excel、PowerPoint、OpenDocument、RTF、メール、PDF、さらには古い.docファイルも直接読み込めます。古い.xlsや.pptはMicrosoft Officeがインストールされていれば自動的に変換されます。画像ファイルは検査され、向きが修正された後1568ピクセルまで縮小され、カメラ情報・GPSデータ・撮影時刻などのメタデータもすべて削除されます。画像認識に対応していないモデルには、WindowsのOCR機能で抽出したテキストのみが渡されます。

逆にcreate_document機能を使えば、StudioForgeやクラウド上のモデルが生成した内容を保存できます。.docx、.xlsx、.pptxといったファイルはChatForge側でPython標準ライブラリのみを用いてMarkdownから作成され、Officeソフトは不要です。作成されたファイルはDocuments\ChatForgeフォルダ内に保存され、重複したファイル名の場合はreport (2).docxといった形で上書きを防ぎます。返答画面には「開く」や「フォルダー内を表示」ボタン付きのカードが現れます。ただしこの機能は小規模なローカルモデルには提供されていません。金魚に四半期ごとの報告書作成を頼むのはユーザーの責任となります。

意図的に備えていない機能

ChatForgeはエージェント機能を持ちません。これは単なるプロンプト上の約束ではなく、構造的な制限です。9種類あるツールのうち8つは参照専用であり、残り1つも自身のフォルダーに新規ファイルを追加するだけで内容を書き換えることはできません。どのツールも外部プログラムの実行や設定変更、ユーザーが添付していないファイルの読み取りは不可能です。fetch_url機能ではプライベートネットワークやローカルアドレス(DNSリバインディングも含む)へのアクセスが制限されます。計算機ツールもeval関数を使えないようホワイトリスト化された仕組みです。APIキーはWindowsの資格情報マネージャーに保存され、ログからは自動的に削除されます。モデルサーバーもアプリケーション終了と同時に停止する設計です。会話履歴は一つだけ保持され、過去のやり取りがすべて保存されることはありません。混乱したモデルが引き起こしうる最大の不具合は誤った回答と新規ファイルの生成に留まるため、これがトレイアシスタントとして許容できる範囲だと考えています。

注意点

  • 標準のWindows環境ではpythonコマンドがMicrosoft Storeのスタブに過ぎません。 常にpy -3.12 -m uv run …を使うか、launchers\配下のランチャーを利用してください。これを怠ると他の処理が始まる前に失敗してしまいます。
  • Copilotキーはホットキーとして使えません。 実際にはWin+Shift+F23であり、Windows側で占有されています。PowerToysによる再割り当てしか解決策がありません(上記参照)。
  • コンパイル成功=正常動作とは限りません。 Qwen3-4BはNPU向けにコンパイルできますが全く使い物にならない出力を生成します。カタログ上でも「避けるべき」と表示され、未検証のモデルには「未テスト」と記載されています。
  • ドライバ更新やスリープ復帰でコンパイルキャッシュが破損することがあります。 設定画面から「モデル」→「キャッシュをクリア」してから再度読み込んでください。バックアップ用のプロバイダーも用意されているため、その間も利用可能です。
  • 小規模モデルは長い会話で性能が低下します。 ツール呼び出しをやめたり無限ループに陥ったりするためです。これは15億パラメータモデルが長いコンテキストを処理できなくなる現象であり、バグではありません。「会話をクリア」するか、より大規模なモデルへ切り替えることを推奨します。
  • 古い.xls/.pptファイルを添付するにはOfficeが必要です。 変換処理は一時ファイル上で隠れて行われます。Officeがない場合は事前に.xlsxや.pptx形式へ保存してください。HEIC形式の写真にはオプションのpillow-heifパッケージが必要で、そうでなければJPEG形式へエクスポートする必要があります。
  • 再配布時のライセンス注意点: 本アプリ自体はMITライセンスですが、トレイ機能を担うpystrayはLGPL-3.0ライセンスで、実行時に修正なしのまま読み込まれます。インストール時点では問題ありませんが、これを含む自己完結型パッケージを配布する場合はLGPLに基づく再リンク義務が発生します。

私自身の所感

最初のコミットから実際に使えるv0.1.0が完成するまで2日しかかかりませんでした。これは開発スピードの証明というより、実績あるコンポーネントを再利用した結果です。監視モジュール、チャットUI、ストリーミングクライアントなどすべて既存プロジェクトから流用しています。NPU対応は比較的容易な部分で、本当の難題は15億パラメータモデルを実用レベルに引き上げること(ツールの絞り込み、事前調査機能、拒否反応の修正など)と機能範囲を制限することでした。エージェント機能や会話履歴保存は用意せず、ユーザーの要望がない限りクラウド通信も行いません。まだ新しくWindows専用のソフトであり、バージョン番号0.1.0は文字通りの意味です。テストスイートが私に「これで進めても大丈夫」という確信を与えてくれました。Pythonテストが1,520件、JSテストが114件あり、CI環境上のWindowsおよびLinuxですべて合格しています。

バージョン情報

本記事執筆時点でのリポジトリ状態(2026年10月2日確認):

$ git log -1 --format='%h %ci'
2edd2d4 2026-10-02 18:04:38 +0900        # ChatForge v0.1.0

$ uv run pytest -q
1520 passed, 6 skipped, 6 deselected in 50.65s   # Linux上、Python 3.13.14にて

$ npm run -s test:js
tests 114 / pass 114 / fail 0                     # Node v24.18.0

Windows側の実行環境はOpenVINO Model Server 2026.4.0(python_onモード)で、使用モデルはOpenVINO/Qwen2.5-1.5B-Instruct-int4-ovです。上記のNPU性能値はリポジトリ内のdocs/RUNTIME-NOTES.mdから引用したもので、そこにはQwen3-4Bの不具合状況も記録されています。

関連記事: StudioForge:GPU専用LLMサーバー · DisPatch:自己ホスト型AIチャット · DeepSeek Harness(dsh)初見解説 · DeepSeekをローカルで動かす:初心者向け4ステップガイド · 私のAIエージェントにかかる実際のコスト:DeepSeekと大規模APIの比較

ダウンロード

個人利用は無料です。役に立ったら、コーヒーをおごってもらえると嬉しいです。


← AIとローカルLLMをもっと見る