「ダウンロードした資料が増えたので、内容を読んで部署別に分けたい」。の新機能は、こうした作業を手元のAIに頼む入口になります。この記事では、日本語の架空ファイル10件を使い、分類案を作る→人が承認する→人が移動するところまでの試験手順を紹介します。
2026年9月27日時点の公式v1.122を確認した解説です。KoboldCpp Agentとモデルを動かした性能レビューではありません。動作確認したのは同梱の教材生成スクリプトで、掲載する分類先は教材の目安です。自動整理の成功率や日本語の判断精度を測定したものではありません。
1. KoboldCppに何が加わったのか
v1.122では、モデルに作業を頼み、必要な道具を呼び出すが同梱されました。公式リリースの公開日時は、日本時間2026年9月26日18時05分です。既存のモデルを読み込む機能に、ファイルを読み書きしたり、必要な情報を探したりする操作の流れが加わった更新と捉えると分かりやすいでしょう。
| 組み込みツール | できること |
|---|---|
| read / glob / grep | 文章を読む、ファイル名を探す、内容を検索する |
| write / edit | ファイルを書き込む、内容の一部を置き換える |
| shell | 端末のコマンドを実行する |
| web_fetch / view_image | Webページを取得する、画像を確認する |
| ask_user | 利用者に質問する |
外部の道具を追加するにも対応します。ただし、この試験では接続を追加しません。まずテキストの読解と分類に絞ると、間違いが「日本語の判断」なのか「外部連携の設定」なのかを切り分けられます。9ツールの定義と実装を確認できます。
2. 起動前に確認するモデルとメモリ
KoboldCppには別途、対応するモデルが必要です。形式のファイルを選ぶ際は、日本語の読解と道具の呼び出しに対応するかを確認します。どのモデルでも同じ判断をするわけではありません。既に使っているモデルがなければ、ローカルLLMの始め方で、機器とモデルの組み合わせから整理してください。
| 項目 | 公式v1.122で示す条件 |
|---|---|
| 配布ファイル | Windows、Linux、Apple Silicon向けを公式リリースから選ぶ |
| コンテキスト | 少なくとも28k。起動時の実装では28,672に不足分を引き上げる |
| 生成量 | 少なくとも8k。起動時の実装では8,192に不足分を引き上げる |
| 機器の目安 | 快適な利用には12GB以上のVRAMを推奨。モデルと設定で必要量は変わる |
や生成量はで数えます。28kは「日本語を2万8千文字読める」という意味ではありません。また、12GBは、あらゆるモデルが収まる保証ではありません。設定値が自動で増えるため、普段チャットだけに使っていた機器ではメモリ不足になる可能性があります。公式の推奨条件と起動時の調整処理を参照してください。
でモデルを選択し、AdminタブのLaunch KoboldCpp Agentを有効にして起動すると、モデルの接続準備後に別の端末が開く実装です。通常のモデル起動コマンドに --agent を加える方法もあります。ただし、--agent だけの起動は既存の接続先を使う別経路なので、初回のモデル読み込み手順と混同しないでください。画面項目と起動分岐を確認しています。
3. 日本語の架空ファイル10件を作る
教材は生成スクリプト、ファイル一覧、分類の目安、使い方です。3.9以降がある環境で、ダウンロードしたスクリプトの内容を確認して実行します。追加ライブラリ、モデルの取得、外部サービスへの接続はありません。
python3 create_sample_files.py --dest koboldcpp-practice新しい koboldcpp-practice/inbox に10件を作ります。同名の保存先が既にあれば中止し、上書きしません。別の試験をするなら保存先を変えてください。教材には請求、見積、画面改修の文書のほか、担当が分からないメモも含めています。分類の目安はinboxの外に保管し、AIへ渡す入力に混ぜません。
ファイル名だけを見ると誤りやすい例も用意しました。「請求書_画面表示不具合」は経理書類ではなく、表示処理を直す依頼です。「見積テンプレ_画面改修仕様」も開発の文書です。こうした例で本文を確認するか、情報が足りないときに保留するかを見ると、単純な名前の仕分けとの違いを確かめられます。
4. 書き込みを止めて、分類案を依頼する
Agentの端末で、生成スクリプトが表示したinboxの絶対パスへ作業先を変更します。次に承認を有効にし、書き込み、編集、コマンド実行、Web取得を無効にします。/tools で状態を確認してから依頼を入力してください。ツール設定を変えると会話が消去されるため、設定を先に済ませます。設定コマンドの実装に基づく手順で、モデルを接続した実行は未検証です。
/workdir "生成時に表示されたinboxの絶対パス"/confirm on/tools write off/tools edit off/tools shell off/tools web_fetch off/tools/workdirこの作業先の直下にある10件のtxtファイルだけを読み、分類案を表示してください。移動・改名・削除・書き込みはしないでください。
分類先は「経理」「営業」「開発」「保留」の4つです。本文の主な依頼に基づき、経理は請求・精算処理、営業は顧客への提案・商談、開発は画面や機能の修正とします。情報不足、複数部署にまたがり保管先を決められないものは保留です。
元のファイル名、分類先、根拠となる短い引用、確認したい点を表にしてください。ファイル名だけでは判断せず、読めないものは未読と書いてください。作業先の外やWebは参照しないでください。読み取りの確認が出たら、パスと引数を見て、教材ファイルへの操作であることを確かめて承認します。本文の引用があると、どこを根拠に分類したかを追えます。読めていないファイルまで分類していたら、その行を採用しません。「終了しました」という返答より、10件すべてに読んだ根拠があるかを確認しましょう。
5. 承認の意味を確かめて、人が整理する
| 承認モード | 動作 |
|---|---|
| on | 既定値。読み書きなどのツール実行前に人が確認する |
| auto | 接続モデルが追加判定し、承認しなかった操作を人へ確認する |
| off | ツール実行を自動承認する |
auto は人が毎回確認する設定ではありません。モデルの追加判定も誤る可能性があります。さらに、/workdir は作業場所を変えるだけで、アクセスを閉じ込めるではありません。実装は絶対パスも受け付けるので、試験フォルダを選んだだけで他のファイルが保護されるとは考えないでください。承認処理と作業先の変更処理を確認できます。
今回はAIに移動を許可せず、分類案を人が採用・修正します。確認したらAgentを /exit で終了し、inbox内に「経理」「営業」「開発」「保留」のフォルダを作って手で移します。この方法なら、分類が適切かを先に評価できます。移動操作の自動化は、判断と実行の両方を確認できるようになってから別の試験として扱います。
| 架空の整理前 | 分類の目安 | 確認するポイント |
|---|---|---|
| 01_2026-09_請求書_あおぞら計画.txt | 経理/元のファイル名 | 入金確認の依頼を読んだか |
| 09_請求書_画面表示不具合.txt | 開発/元のファイル名 | 名称に引かれず表示修正と判断したか |
| 07_次回対応メモ.txt | 保留/元のファイル名 | 不足情報を勝手に補っていないか |
| 10_議事録_部門合同.txt | 保留/元のファイル名 | 複数部署の内容を一つへ押し込めていないか |
整理後は、元の10件がすべて残っているか、同じファイルが二つのフォルダに紛れていないか、名前と本文が変わっていないかを確認します。分類の目安との差だけでなく、自分が直した理由も残してください。「内容を誤読した」のか「社内の保管ルールが曖昧だった」のかで、次に直す場所が変わります。
6. 何を記録すれば、仕事で使えるか判断できるか
記録するのは、KoboldCppの版、モデル名とファイル名、コンテキスト設定、実行した日時、10件ごとの分類案と人の判断です。待ち時間を測るなら、最初にモデルを読み込む時間と、依頼してから回答する時間を分けます。別のモデルと比べるときも、教材・依頼文・設定をそろえないと、どこが改善したか分かりません。
この10件は動作を理解するための教材です。全部が分類できても、大量の資料や実際の社内文書で同じ精度が出るとは限りません。長い文書では読み取り結果が途中で切れることがあり、日本語を得意とする程度もモデルに依存します。今回の試験は文章だけなので、画像や表を含む資料の読み取り性能も評価しません。
まずは、本文の根拠を示すこと、曖昧な文書を保留すること、人が確認してから作業することの3点を見てください。AIを使った議事録の確認手順も、文書の内容を確かめる際の参考になります。ファイル整理を入口に、自分の仕事で任せられる範囲を少しずつ広げていきましょう。