GPT-4.1 miniで変更履歴をタスク一覧にまとめる：APIの設定と結果の読み方

GPT-4.1 miniは、OpenAIが2025年4月14日に公開したGPT-4.1シリーズの小型モデルです。テキストと画像を入力し、テキストを出力します。指示への追従、長い文脈の処理、関数呼び出しなどに対応しており、複数の文書から必要な情報を取り出す処理も用途の一つです。

2026年にあえてこのモデルを取り上げるのは、担当者や期限の抽出なら、必要な仕事をかなり具体的に定義できるからです。2026年10月30日に確認したOpenAI公式のAPI料金では、GPT-4.1 miniのStandardのテキスト入力・出力単価は、より新しいフラッグシップのGPT-6 Astraより低く設定されています。小さな処理を任せる候補にはなりますが、修正にかかる手間も含めて判断したいところです。これは公式単価の比較であり、以下のCrazyrouter経由の実測料金ではありません。

そこで私は、元の依頼書と複数の変更通知を渡し、「現在の担当者・期限・完了条件」を一つのタスクにまとめられるか試しました。変更を正しく組み合わせた例がある一方、期限の矛盾を見つけてもステータスを更新しない例が残りました。この記事では、接続方法から、文書を渡す際のルールと結果の確認までを説明します。

資料確認・実測日は2026年10月30日です。実験の文書、プロンプト、回答は中国語簡体字で、日本語での性能を測ったものではありません。

GPT-4.1 miniに任せる処理を決める

OpenAIのモデル文書に記載されたコンテキストウィンドウは1,047,576トークン、最大出力は32,768トークン、知識の基準日は2024年6月1日です。関連文書をまとめて渡す余地はありますが、この長さまで正しく読めることや、同じ長さの回答を出せることを保証する数字ではありません。

たとえば、元の仕様書で決まった保存期間は変わっていないのに、後の通知で担当者だけが変わることがあります。最新の文書だけを要約すると、保存期間が抜けます。文書ごとに要約を並べても、最後に人が統合する作業は残ります。今回モデルに任せたかったのは、この統合です。

画像の説明やコードの読解も文書上の能力から考えられる用途ですが、今回は試していません。関数呼び出しにも対応していますが、外部システムを操作するのはアプリケーション側です。モデルにタスク一覧を作らせたことと、そのままタスク管理サービスを更新してよいことは分けて考えます。

API接続ではBase URLとモデルIDを分けて設定する

今回使ったのはCrazyrouterのOpenAI互換Chat Completions APIです。OpenAI APIという別の利用経路もありますが、ここでは実際に使った接続先を示します。CrazyrouterのアカウントでAPIキーを発行し、利用条件を確認したうえで、GPT-4.1 miniのモデルページと照合して設定します。

Base URL: https://api.crazyrouter.com/v1
Model: gpt-4.1-mini
API key: 自分のCrazyrouterキーを安全な設定から読み込む

OpenAI互換の接続先を指定できるクライアントでは、それぞれ対応する欄に設定します。HTTPで直接呼ぶ場合は、https://api.crazyrouter.com/v1/chat/completionsへのPOSTです。認証はBearer、本文はJSONを使います。クライアントがパスを付ける場合、Base URLに/chat/completionsを重ねて書かないようにします。キーは公開コードや共有画面に含めません。

最初の接続確認には、答えが分かる短い文書を使います。次は、要求の形を説明するための日本語の例です。下で紹介する中国語の正式実験と同じリクエストではなく、この日本語例自体はAPIで実行していません。

{
  "model": "gpt-4.1-mini",
  "messages": [
    {
      "role": "system",
      "content": "文書から担当者と期限を抽出し、ownerとdeadlineを持つJSONオブジェクトを返してください。書かれていない値はnullにしてください。"
    },
    {
      "role": "user",
      "content": "テスト文書：担当は田中。期限は2026年11月9日。"
    }
  ],
  "temperature": 0,
  "max_tokens": 6000,
  "stream": false,
  "response_format": { "type": "json_object" }
}

回答本文はchoices[0].message.contentに入ります。HTTPの成功だけでなく、本文が空でないか、途中で切れていないか、JSONを読めるか、値が文書と合っているかを確認します。上の例なら、担当者と日付を原文に照らせます。その後で期限変更の文書を一つ足せば、接続の問題と文書解釈の問題を切り分けやすくなります。

正式実験もtemperature=0、max_tokens=6000、stream=false、response_format=json_objectで行いました。これは今回の条件であり、最適値の提案ではありません。JSONモードを使いましたが、strict JSON Schemaは送っていません。

「最新の文書」より先に「いつの状態か」を指定する

正式実験では、12タスクに関する51本の短い文書を用意しました。原本、承認済み変更、下書き、議論、同じタスクIDを持つ過去案件の記録を含みます。人物と出来事はすべて実験用に作ったものです。正式リクエストの入力は各26,430トークンで、100万トークンの限界を試したわけではありません。

出力はタスクごとにid、owner、deadline、status、acceptance、sources、conflictsを持たせました。単なる要約ではなく、次のルールで状態を組み立てるよう依頼しています。

• 仮の基準時点を2026年10月30日18時とし、その時点で有効な変更だけを適用する。
• 変更通知に明記された項目だけを更新し、触れていない条件は引き継ぐ。
• 下書きや別の過去案件を根拠に、現在の値を上書きしない。
• 情報がなければnullにする。優先順位の決まらない矛盾は候補と出典を残し、状態を「要確認」にする。

この時点の指定が効いたのがT06です。承認済みでも11月2日から有効になる変更は、10月30日の状態には反映させません。2回とも、元の担当者と「上位20件を返す」という条件が残り、将来の「50件」には変わっていませんでした。

T01では担当者と期限を別々の変更から組み合わせた

T01の原本B01には、担当者が周宁（Zhou Ning）、期限が11月4日、監査記録を180日保存するという条件がありました。C01は期限を11月9日に変更し、C02は担当者を郑言（Zheng Yan）に変更します。ほかの条件は維持する指定です。

GPT-4.1 miniは担当者を郑言、期限を2026年11月9日とし、180日の保存条件も残しました。出典にはB01、C01、C02が入り、2回の正式回答で一致しています。

図1：仮想文書と1回目の正式回答をもとに作成した説明図です。原値は中国語、補足は英語のままにし、本文で日本語の意味を説明しています。画面のスクリーンショットではありません。項目ごとの出典対応は私が原文と照合したもので、APIが返した出典はタスク全体のリストです。

この結果なら、文書を読み直して現在値を組み立てる作業の一部をモデルに任せられる可能性があります。ただし、担当者欄をクリックすると根拠の一文が開くような機能まで検証したわけではありません。そこまで必要なら、出典の位置情報も設計し、別途確認する必要があります。

T02では期限の矛盾がステータスに反映されなかった

T02には、11月10日と11月12日をそれぞれ期限とする、同じく有効な二つの決定がありました。どちらを優先するかは決まっていません。モデルはdeadlineをnullにし、二つの候補と出典を残しました。勝手に一方を選ばなかった点は役に立ちます。

ところがstatusは待办、つまり「未着手」のままでした。今回求めたのは待确认、つまり「要確認」です。さらにconflictsは文字列の配列を要求したのに、配列の中に別の配列が入っていました。JSONの構文としては読み取れるため、パースできたことだけでは見逃します。

図2：保存済み回答から、適用前の変更と未解決の矛盾を並べた説明図です。中国語の原値と英語の解説を保持しています。誤ったステータスと配列構造は修正していません。図中の次の対応は提案であり、モデルに再実行させた結果ではありません。

タスク管理に取り込むなら、私は出力の型に加えて、項目間の関係を確認します。「未解決の期限があるのに通常の未着手タスクになっている」という組み合わせを止めたいからです。一方、T03の担当者・期限がnullなのは元資料に情報がないためで、矛盾と同じ理由ではありません。空欄だけで自動的に「期限衝突」と判定するのも違います。

最初に試すなら、正解を知っている変更履歴を残す

私は呼び出し前に正解データを用意し、プログラムで比較したうえで原文も読み直しました。同じ12タスクを2回呼び、どちらも主要項目は47/48、出典の確認は12/12行、構造は11/12行が通りました。T02が残るため、どちらも全体の要件は満たしていません。

その前に3タスクで1回試しており、生成リクエストは合計3回です。修正のための再呼び出しや回答の手直しはしていません。同じ問題を2回観察した結果であって、独立した24タスクでの性能ではありません。

利用期間にも注意が必要です。OpenAIは2026年10月14日の告知で、gpt-4.1-mini-2025-04-14を2027年1月14日にOpenAI APIから削除する予定としています。今回Crazyrouterで応答が得られたことから、同サービスの将来の提供期間までは分かりません。

試すなら、現在の提供状況と課金条件を確認してから、答えを把握している短い文書で接続し、担当者変更、期限変更、矛盾のある決定を順に足してみます。今回の結果では、変更の統合には使いどころがありました。次に選ぶモデルでも同じ資料と期待値を残しておけば、「きれいに要約できた」より具体的な基準で、その処理を任せられるか判断できます。