DeepSeekのnum_ctxを完全解説！設定次第で生成速度が激変する仕組みと最適な使い方まとめ

「DeepSeekをOllamaで動かしたら急に遅くなった」「num_ctxって何を設定すればいいの？」と悩んだことはないだろうか。実はこのパラメータひとつで、生成速度が10倍以上変わることもある。本記事では、Ollamaで話題のローカルLLM「DeepSeek R1」を動かす際に避けて通れない num_ctx（コンテキストウィンドウサイズ） の仕組みを、GitHubのIssueや実際のデプロイ記録などをもとに徹底的に調査してわかりやすくまとめた。

num_ctxを大きくしすぎると「なぜかGPUがほぼ使われず、1文字/秒まで落ちた」「KVキャッシュがRAMを食い尽くして落ちた」といった事態が頻発している。この記事では、そのメカニズムを根本から理解したうえで、モデルサイズ・VRAM量・用途に合った現実的な設定値の選び方まで具体的に解説していく。読めばnum_ctxについてAI回答を探し回る必要がなくなるはずだ。

この記事のポイント
✅ num_ctxとは何か、Ollamaでどう機能するかを基礎から理解できる
✅ num_ctxを増やすと生成速度が激落ちするメカニズムがわかる
✅ DeepSeek R1の規模別・VRAM別の現実的な設定値を把握できる
✅ num_gpu・num_threadとの組み合わせで性能を最大化する方法がわかる

今日のセールをまとめてチェック！

本日のセール・タイムセールをまとめてチェックできます。

Amazon

＼楽天ポイント4倍セール！／

楽天市場

＼商品券4%還元！／

Yahooショッピング

メルカリ

ポチップ

DeepSeekのnum_ctxとは何か、なぜ重要なのかを徹底解説

DeepSeekのnum_ctxとはコンテキストスロット数＝会話の記憶量のこと
num_ctxを大きくすると生成速度が激落ちする本当の理由
Ollamaのデフォルトnum_ctx「2048」が小さすぎる場面とその弊害
num_ctxとKVキャッシュの関係：メモリ消費が爆増するメカニズム
num_ctxの変更方法はOllamaで3ステップで完了する
num_ctxの推奨値は用途ごとに異なる

DeepSeekのnum_ctxとはコンテキストスロット数＝会話の記憶量のこと

num_ctx とは、OllamaでLLMを動かす際に指定する「コンテキストウィンドウのサイズ（トークン数）」を意味するパラメータだ。

LLMは会話や文章を処理する際、過去のやり取りをすべてメモリ上に保持しながら次のトークンを予測している。このとき「どこまで遡って記憶するか」を決めるのがnum_ctxの役割になる。たとえばnum_ctx＝2048に設定した場合、モデルは直近2,048トークン分の文脈しか参照できない。

「num_ctx for ollama refers to the number of context slots or the number of contexts the model can maintain during inference.」
（引用元：https://ollama.com/huihui_ai/deepseek-r1-pruned:411b）

つまり「モデルが推論中に維持できるコンテキスト（文脈）の数」と定義されている。1トークンはおおよそ0.75〜1単語に相当するため、日本語では1文字〜数文字に対応する。

📋 num_ctxの基礎知識まとめ

項目	内容
パラメータ名	num_ctx
意味	コンテキストウィンドウのトークン数
Ollamaデフォルト	2,048トークン
DeepSeek R1の学習時コンテキスト	131,072トークン
設定コマンド（Ollama）	`/set parameter num_ctx 8192`

DeepSeek R1シリーズのモデルは最大131,072トークンの学習コンテキストを持っているが、Ollamaのデフォルト設定ではわずか2,048トークンしか使われない。これは学習時の能力をほぼ使い切れていない状態だ。ただし、コンテキストを増やせば増やすほどメモリと処理速度に深刻な影響が出るため、単純に大きくすればいいわけではない。

num_ctxを大きくすると生成速度が激落ちする本当の理由

実際にDeepSeekを動かしているユーザーから「num_ctxを増やしたら異常に遅くなった」という報告が複数上がっている。GitHubのOllama公式Issueでも、この問題は繰り返し取り上げられている。

「When num_ctx is not set, the generation speed is very fast, but the model will exit after the input and output become too long. Then, I used the Python interface of ollama and modified the size of the num_ctx parameter, which solved the issue, but the speed of model generation became very slow.」
（引用元：https://github.com/ollama/ollama/issues/9182）

つまり「num_ctxを設定しないと速いが文脈が切れる」「num_ctxを増やすと文脈は保てるが遅くなる」というトレードオフが生じているわけだ。

この速度低下の根本原因は KV（Key-Value）キャッシュ にある。LLMは各レイヤーで過去の全トークンのKey・Valueベクトルをキャッシュし、次の推論に使う。num_ctxが2倍になれば、このキャッシュに必要なメモリも2倍以上になる。

📊 num_ctxとKVキャッシュサイズの関係（DeepSeek R1 70B・実測値参考）

num_ctx	KVキャッシュ合計	GPUへのオフロード状況
2,048（デフォルト）	約640MB	全レイヤーGPU（CUDA）上
121,344	約37,920MB	CPU主体・GPU補助
131,072（最大）	約41,000MB超（推定）	ほぼCPUオンリーになる場合あり

この数字を見ると、num_ctxを約60倍にすると、KVキャッシュも約60倍になることがわかる。大きなコンテキストを使おうとすると、キャッシュがVRAMに乗り切らなくなり、CPU RAMに追い出される。CPUとGPUの帯域幅の差は文字通り「桁違い」なので、処理速度が劇的に落ちるのは当然の結果といえる。

Ollamaのデフォルトnum_ctx「2048」が小さすぎる場面とその弊害

Ollamaはインストール直後、num_ctxのデフォルト値を 2,048トークン に設定している。この値はハードウェアへの負担を最小化する保守的な設定だが、実際のユースケースでは不十分なことが多い。

コーディング支援ツール「16x Prompt」の公式ガイドには次のような記述がある。

「Ollama defaults to 2048 context window size, which is too small for most coding tasks. You can adjust the context window size to 8192.」
（引用元：https://prompt.16x.engineer/guide/ollama）

コーディングのような長いコードブロックや複数ファイルを扱う作業では、2,048トークンだと途中で文脈が切れてしまう。その結果、モデルが冒頭の指示を「忘れた」状態で回答するため、一見してそれらしいが的外れな回答が生成されることになる。

⚠️ num_ctx 2048が不足しやすいシナリオ

✅ 長文コードのレビューやリファクタリング
✅ 複数ターンにわたる長い会話・議論
✅ 大量のドキュメントを読ませてのQ&A
✅ 長文翻訳・要約タスク
✅ 数千行を超えるログ解析

一方、短い質問への回答や単発の翻訳であれば2,048でも十分なケースもある。用途に応じて適切な値を選ぶことが重要だ。

num_ctxとKVキャッシュの関係：メモリ消費が爆増するメカニズム

LLMの推論における KV（Key-Value）キャッシュ とは、Transformerの各アテンションレイヤーが過去のトークンを再計算せずに再利用するための仕組みだ。これがあるおかげで、逐次生成（一度に1トークンずつ生成する処理）が効率的に行われる。

num_ctxを増やすと、各レイヤーで保持するKV行列のサイズが比例して増大する。DeepSeek R1 70Bのような大型モデルで、実際のログから確認できた数値を示す。

📋 DeepSeek R1 70B・num_ctx別のKVキャッシュ配置（実ログ参考）

設定	KVキャッシュ配置	生成速度の傾向
num_ctx＝2,048	CUDA0〜3に各160〜168MB（合計640MB）	高速（GPUフル活用）
num_ctx＝121,344	CPU：28,914MB＋CUDA0〜3に各2,844MB（合計37,920MB）	極低速（CPU主体）

（参考：https://github.com/ollama/ollama/issues/9005 のログより）

num_ctx＝2,048の場合、KVキャッシュ640MBはVRAMに問題なく収まるため、全レイヤーがGPU上で高速に動く。

ところがnum_ctx＝121,344に設定した途端、KVキャッシュが約37,920MBまで膨れ上がり、GPU 4枚合計のVRAM（この例では4×24GB＝96GB）でも到底収まらない。結果として、大部分がCPU RAM（コンピュータの一般的なメモリ）に配置されることになる。

GPUのメモリ帯域幅は数百GB/sなのに対し、CPUのメモリ帯域幅はその数十分の一程度にとどまる。この差がそのまま生成速度の差として現れるため、「1文字/秒」というような極端な低速が発生するわけだ。

num_ctxの変更方法はOllamaで3ステップで完了する

Ollamaでnum_ctxを変更する方法はいくつかある。大きく分けると「対話中に一時的に設定する方法」と「モデルファイルに恒久的に書き込む方法」の2種類だ。

📋 Ollamaでのnum_ctx設定方法一覧

方法	コマンド例	永続性
対話セッション内で設定	`/set parameter num_ctx 8192`	そのセッションのみ
保存して新モデル化	`/set parameter num_ctx 8192` → `/save モデル名-8k`	永続（新モデルとして保存）
Modelfileに記述	`PARAMETER num_ctx 8192`	永続（Modelfile管理）
Python APIで指定	`options={"num_ctx": 8192}`	リクエストごと

🔧 ステップ①：Ollamaを起動してモデルを実行する

ollama run deepseek-r1:14b

🔧 ステップ②：対話モードでnum_ctxを設定する

/set parameter num_ctx 8192

🔧 ステップ③：設定を保存して新しいモデル名で管理する

/save deepseek-r1:14b-8k

この手順で deepseek-r1:14b-8k という名前のカスタムモデルが作られ、次回以降 ollama run deepseek-r1:14b-8k で呼び出すだけでnum_ctx＝8192が適用された状態で起動できるようになる。

Modelfileに直接書く場合は以下のように記述する。

FROM /path/to/model.gguf
PARAMETER num_gpu 28
PARAMETER num_ctx 4096
PARAMETER temperature 0.6

（参考：https://snowkylin.github.io/blogs/a-note-on-deepseek-r1.html）

num_ctxの推奨値は用途ごとに異なる

「num_ctxはいくつにすれば正解？」という問いへの答えは、残念ながら一概には言えない。なぜなら、適切な値はモデルサイズ・VRAM量・用途の3つによって大きく変わるからだ。

📊 用途別・num_ctx推奨値の目安

用途	推奨num_ctx	理由
軽い雑談・短文QA	2,048〜4,096	短い文脈で十分、高速重視
コーディング支援	8,192〜16,384	コードブロックが長くなりやすい
長文ドキュメント分析	16,384〜32,768	大量テキストを一度に扱う
長期対話・複雑な推論	32,768〜65,536	多ターンの会話履歴を保持
DeepSeek R1フルスペック	最大131,072	VRAM・RAM十分な場合のみ

一般的には、まず小さな値（2,048〜4,096）で動作確認し、「文脈が切れる」と感じたら徐々に増やしていくアプローチが安全だ。増やすたびにメモリ使用量と速度をモニタリングしながら、自分のハードウェアが耐えられる上限を探っていくのが現実的な進め方といえる。

忘れる前に！【ふるさと納税】今年もお得に！

ふるさと納税のポイント付与は2025年10月に廃止になりました。

Amazon

＼楽天ポイント4倍セール！／

楽天市場

＼商品券4%還元！／

Yahooショッピング

メルカリ

ポチップ

DeepSeekのnum_ctxを使った実践的な最適化と設定のコツ

num_ctxを大きくするとGPUからCPUに処理が移る問題の原因と対処法
num_gpuとnum_ctxの組み合わせが性能を左右する
num_threadの設定もセットで考えるとCPU負荷が激減する
DeepSeek R1 671Bでのメモリ・num_ctx設定の実際の事例
num_ctxを増やしてもクラッシュしないための注意点
num_ctxに関するよくある疑問をQ&A形式で解決する
総括：deepseek num_ctxのまとめ

num_ctxを大きくするとGPUからCPUに処理が移る問題の原因と対処法

num_ctxを大きく設定したとき、GPUリソースがほとんど使われなくなるという現象は、実際のユーザーからも報告されている。

「Also, it was found that almost no GPU resources were used. deepseek-r1:70b_121234 ffb79c778740 156 GB 41%/59% CPU/GPU」
（引用元：https://github.com/ollama/ollama/issues/9005）

GPU 41%・CPU 59%という数字が示すように、num_ctx＝121,344を設定した途端にCPU主体の処理になってしまっている。これはKVキャッシュがVRAMからはみ出し、CPUメモリに配置されたことが直接の原因だ。

📋 GPU→CPU移行が起きる原因と対処法

原因	対処法
KVキャッシュがVRAMを超えた	num_ctxを下げるか、num_gpuレイヤー数を減らしてKV用VRAMを確保する
VRAMが足りずモデルレイヤーがCPUに逃げた	num_gpuを下げてKVキャッシュに必要なVRAMを意図的に空ける
スワップ領域が使われている	推奨しないが、システムのスワップを増やして対処するケースもある
モデル自体が大きすぎる	より軽量な量子化バージョン（Q4_K_M等）に切り替える

対処の基本原則は「KVキャッシュが必ずVRAMに収まるようにnum_ctxを調整する」こと。どうしても大きなコンテキストが必要なら、GPU層数（num_gpu）をあえて減らして空けたVRAMをKVキャッシュ専用に使う方法も一定の効果があるとされている（ただしレイヤーがCPUに移るトレードオフがある）。

また、スワップ（仮想メモリ）への依存は速度を著しく低下させるため、基本的には避けたほうがいい。Ollamaのデプロイノートにも「スワップへの依存は推奨しない」と明記されている。

num_gpuとnum_ctxの組み合わせが性能を左右する

num_ctxだけ調整してもうまくいかないことが多い。セットで考えるべきなのが num_gpu（GPUにオフロードするレイヤー数）だ。

「num_gpu: number of layers to be offloaded to GPUs. DeepSeek R1 has 61 layers.」
「For DeepSeek-R1-UD-IQ1_M, 7 layers can be offloaded to each of my RTX 4090 GPU (24 GB VRAM). I have four of them so I can offload 28 layers.」
（引用元：https://snowkylin.github.io/blogs/a-note-on-deepseek-r1.html）

DeepSeek R1は全61レイヤーで構成されている。RTX 4090（VRAM 24GB）なら1枚あたり約7レイヤーがオフロード可能という実測値がある。4枚挿せば28レイヤーまでGPUで処理できる計算だ。

📊 GPU構成別のnum_gpu設定目安（DeepSeek R1 671B・1.73bit量子化版）

GPU構成	VRAM合計	num_gpu目安	備考
RTX 4090 × 1	24GB	7	KVキャッシュ用にVRAMを確保する必要あり
RTX 4090 × 2	48GB	14	中規模なコンテキストなら現実的
RTX 4090 × 4	96GB	28	著者の実測値（IQ1_M版）
H100 80GB × 2	160GB	61（全層）	高速推論が可能（>10 tokens/s）
H100 80GB × 8	640GB	61（全層）	Q4_K_M版もGPUに乗る

VRAMが大きければ大きいほど、多くのレイヤーをGPUにオフロードでき、かつKVキャッシュにも余裕が生まれる。逆にVRAMが小さい場合は、num_gpuとnum_ctxの両方を控えめに設定してバランスを取る必要がある。

まず ollama run モデル名 --verbose で起動し、ログに表示される「offloaded X/61 layers to GPU」の数字と「KV buffer size」を確認しながら調整するのが確実な方法だ。

num_threadの設定もセットで考えるとCPU負荷が激減する

num_ctxを大きくした結果、CPUでの処理が増えるケースでは num_thread（使用するCPUコア数）の設定も重要になってくる。

「num_thread refers to the number of cores in your computer, and it’s recommended to use half of that, Otherwise, the CPU will be at 100%.」
（引用元：https://ollama.com/huihui_ai/deepseek-r1-pruned:411b）

推奨はCPUの物理コア数の半分だ。すべてのコアをLLMに使わせると、OSや他のアプリが使うリソースがなくなり、システム全体が応答不能に近い状態になることがある。

📋 num_thread設定の指針

CPUコア数	推奨num_thread	備考
8コア	4	一般的なデスクトップPC
16コア	8	ミドルレンジのワークステーション
32コア	16	サーバー向けCPU（Xeon等）
64コア	32	ThreadRipper・EPYC等

/set parameter num_thread 16

このように /set parameter num_thread [コア数の半分] で設定できる。Modelfileに書く場合も同様に PARAMETER num_thread 16 と記述すればよい。

また、CPUメモリ（RAM）の容量もnum_ctxに直結する。おおよその目安として、num_ctxを4倍にするごとにKVキャッシュのRAM消費も4倍以上になると考えておくと安全だ。32GB RAMなら現実的に使えるnum_ctxの上限はかなり制限されるが、192GB以上のRAMがあれば大きなコンテキストも扱いやすくなる。

DeepSeek R1 671Bでのメモリ・num_ctx設定の実際の事例

DeepSeek R1の最大版である671Bモデルは、そのサイズゆえに特別な注意が必要だ。実際に動かしているユーザーの事例を整理してみた。

📋 DeepSeek R1 671Bの量子化バージョン比較

モデル	サイズ	量子化	必要メモリ目安
DeepSeek-R1-UD-IQ1_M	158GB	1.73bit（動的）	RAM+VRAM≧200GB
DeepSeek-R1-UD-IQ1_S	131GB	1.58bit（動的）	RAM+VRAM≧200GB
DeepSeek-R1-Q4_K_M	404GB	4bit標準	RAM+VRAM≧500GB

（参考：https://snowkylin.github.io/blogs/a-note-on-deepseek-r1.html）

📊 DeepSeek R1 671B（IQ1_M）の生成速度実測値（参考）

条件	速度
RTX 4090 × 4、短文生成（〜500トークン）	7〜8 tokens/s
CPU推論のみ（GPU非使用）	4〜5 tokens/s
長文生成・コンテキスト増大時	1〜2 tokens/sまで低下
H100 80GB × 2	10 tokens/s以上

コンテキストが長くなるにつれて生成速度が落ちていくのは避けられない傾向だ。大きなコンテキストでDeepSeek R1を使う場合は、そもそも「長い思考プロセスや長期の会話には向いていない」という前提で設計することが現実的なアプローチといえる。

また、8xH100（$200k規模のマシン）でも671Bモデルをぎりぎり収容できるレベルであるため、個人・中小規模での運用では量子化モデル＋現実的なnum_ctxの設定が基本路線になる。

num_ctxを増やしてもクラッシュしないための注意点

num_ctxを大きくした場合、OOM（メモリ不足）エラーやセグメンテーションフォルト、Ollamaのクラッシュが発生することがある。実際にGitHubのIssueでも報告されている。

「I’m experiencing constant crashes of ollama 0.5.7 and deepseek-r1:671b, even increasing the context window with the command /set parameter num_ctx 4096.」
（引用元：https://github.com/ollama/ollama/issues/8614）

「Hi, I’ve been using the Deepseek-R1 671B model from Ollama on my 8x H100 machine and keep running into a segmentation fault, I’ve noticed that the frequency of the segfault happens the larger the context becomes.」
（引用元：https://github.com/ollama/ollama/issues/8602）

クラッシュを防ぐための実践的なチェックリストをまとめた。

✅ クラッシュを防ぐためのnum_ctx設定チェックリスト

[ ] 最初はnum_ctx＝2,048でモデルが正常起動するか確認する
[ ] ollama run モデル名 --verbose でKVキャッシュサイズとオフロード層数をログで確認する
[ ] num_ctxを増やす場合は段階的に（2倍ずつ）テストする
[ ] VRAMとRAMの空き容量が十分にあるか事前に確認する
[ ] Ollamaのログ（journalctl -u ollama）でエラーを監視する
[ ] OOMが発生したらnum_ctxを下げるか、スワップを増やす（最終手段）
[ ] 大きなコンテキストで必要な場合は num_predict で最大出力トークン数を制限する

特に「段階的に増やしてログを確認する」という手順を省くと、いきなりシステム全体がフリーズするリスクがある。面倒でも一段ずつ確認することが最短ルートといえる。

num_ctxに関するよくある疑問をQ&A形式で解決する

現場でよく出るnum_ctxにまつわる疑問をQ&A形式で整理した。

❓ Q1：num_ctxはモデルの「賢さ」に影響する？

直接の影響はない。num_ctxはあくまで「どこまで遡って文脈を参照できるか」の範囲を決めるパラメータだ。範囲内のトークンに対する推論精度はモデルの量子化品質や学習データに依存する。ただし、コンテキストが切れることで「直前の指示を忘れた」ような誤った回答が増えるため、間接的に品質に見えることはある。

❓ Q2：num_ctxを131,072（最大値）に設定すれば一番いい？

おそらくそうではない。131,072に設定するとKVキャッシュが数十GB規模になり、大半のユーザー環境ではVRAMどころかRAMにも収まりきらない。結果として生成速度が壊滅的になるか、OOMでクラッシュする可能性が高い。

❓ Q3：num_ctxを増やしたら「n_ctx_per_seq < n_ctx_train」という警告が出た

これは「設定したコンテキスト数が学習時の最大値より小さい」という情報ログだ。エラーではなく、モデルの全能力を使い切れていないことを示している。たとえば n_ctx_per_seq (2048) < n_ctx_train (131072) という表示は「2,048しか使っていないが、最大131,072まで学習している」という意味だ。

❓ Q4：CPUのみで動かす場合、num_ctxはどうすべき？

CPUだけで動かす場合、GPUオフロードによる高速化がないため、num_ctxはより慎重に設定すべきだ。KVキャッシュがRAMに完全に収まる範囲（システムRAMの50%以内を目安にするとよいかもしれない）に抑えることで、ある程度現実的な速度を維持できる可能性がある。

❓ Q5：num_ctxをPython APIから設定する方法は？

OllamaのPython SDKを使う場合、以下のように options パラメータで指定できる。

from ollama import chat

response = chat(
    model='deepseek-r1:14b',
    messages=[{'role': 'user', 'content': '質問内容'}],
    options={'num_ctx': 8192}
)

リクエストごとに動的に変更できるため、タスクの種類によってコンテキストサイズを切り替える柔軟な運用が可能だ。

総括：deepseek num_ctxのまとめ

最後に記事のポイントをまとめます。

num_ctxとはOllamaでDeepSeekを動かす際の「コンテキストウィンドウのトークン数」を指定するパラメータである
Ollamaのデフォルトはnum_ctx＝2,048であり、コーディングや長文タスクでは不足することが多い
num_ctxを増やすと、それに比例してKVキャッシュが増大し、VRAM・RAM消費が急増する
KVキャッシュがVRAMに収まらなくなると処理がCPUに移り、生成速度が劇的に低下する
DeepSeek R1 70Bの場合、num_ctx＝2,048でKVキャッシュ約640MB（GPU上）、num_ctx＝121,344で約37,920MB（CPU主体）になる実測値がある
num_gpuはGPUにオフロードするレイヤー数であり、num_ctxと組み合わせて設定する必要がある
num_threadはCPUコア数の半分が推奨値であり、全コアを使うとシステム全体が不安定になる
num_ctxを大きくする際は段階的に増やし、Ollamaのログでメモリとオフロード状況を確認することが重要である
DeepSeek R1 671Bはモデルサイズが158〜404GBと巨大で、現実的にはRAM+VRAM合計200GB以上が必要になる
クラッシュやセグメンテーションフォルトを防ぐには、num_ctxの上限を自環境のVRAM＋RAMに収まる範囲で設定することが基本である
用途別の推奨num_ctxは「短文QA：2,048〜4,096」「コーディング：8,192〜16,384」「長文ドキュメント：16,384〜32,768」が目安である
Python APIではリクエストごとにnum_ctxを動的に指定でき、タスク別の柔軟な運用が可能である

記事作成にあたり参考にさせて頂いたサイト

各サイト運営者様へ
有益な情報をご公開いただき、誠にありがとうございます。
感謝の意を込め、このリンクはSEO効果がある形で設置させていただいております。
※リンクには nofollow 属性を付与しておりませんので、一定のSEO効果が見込まれるなど、サイト運営者様にとってもメリットとなれば幸いです。
当サイトは、インターネット上に散在する有益な情報を収集し、要約・編集してわかりやすくお届けすることを目的としたメディアです。
引用や参照の方法に不備、あるいはご不快に感じられる点がございましたら、お問い合わせフォームよりご連絡ください。
今後とも、どうぞよろしくお願いいたします。

AI 業務効率化職場

当サイトについて

当サイトでは、インターネット上に散らばるさまざまな情報を収集し、AIを活用しながら要約・編集を行い、独自の切り口で見解を交えながらわかりやすい形でお届けしています。情報の整理・編集にあたっては、読者やオリジナル記事の筆者へご迷惑をおかけしないよう、細心の注意を払って運営しておりますが、万が一、掲載内容に問題がある場合や修正・削除のご要望がございましたら、どうぞお気軽にお問い合わせください。迅速に対応をさせていただきます。その際には、該当記事の URLやタイトルをあわせてお知らせいただけますと、より速やかに対応することができますのでそちらもご協力いただけますと大変幸いでございます。今後とも当サイトをよろしくお願いいたします。