コンテキストとは｜IT・プログラミング・AIでの意味を分野別に実演

どの分野でも「その場の前提をひとまとめにして持ち運ぶもの」という点は同じで、中身だけが違います。

flowchart LR
    A[コンテキスト<br>前提となる情報] --> B[プログラム<br>this・ctx]
    A --> C[OS<br>レジスタ等の状態]
    A --> D[生成AI<br>入力トークン全体]
    A --> E[設計<br>用語が通じる範囲]
    A --> F[一般語<br>文脈・背景]

よく出会う順に、分野ごとの意味をまとめました。

確認環境：Ubuntu 24.04.4・Linux カーネル 6.18（CPU 2個）・Node.js 22.22.2・Go 1.24.7・Python 3.11.15・React 19.3.1（react-dom/server で描画）・js-tiktoken 1.0.21（o200k_base・cl100k_base）・vmstat（procps-ng 4.0.4）・pidstat（sysstat 12.6.1）。JavaScript の this、Go の context（タイムアウト・キャンセル・HTTP の切断）、Python の with と contextvars、React Context、コンテキストスイッチの回数、トークン数はすべて実際に動かした出力です。生成AIのモデルごとの上限は Anthropic・OpenAI・Google の公式ドキュメント、仕様の説明は MDN・Go 公式・React 公式・Python 公式・Linux man-pages・Kubernetes 公式・Martin Fowler の解説で確かめました（確認日 2026年10月17日）。

コンテキストとは（IT用語の意味）

コンテキスト（context）は、英語で「文脈・前後関係・状況」という意味の言葉です。 IT では「ある処理が、それを前提にして動く情報のまとまり」を指します。同じ命令でも、前提が変われば結果が変わります。その「前提」がコンテキストです。

• JavaScript の this.name は、どのオブジェクトから呼ばれたか（前提）で値が変わる
• Go のデータベース問い合わせは、渡された ctx の期限（前提）を過ぎると止まる
• 生成AIの答えは、それまでの会話やファイル（前提）が入力に含まれているかで変わる

「コンテクスト」と書いても同じ言葉です。IT の文書やツールの画面では「コンテキスト」が多く使われます。

コンテキスト・ステート・セッション・スコープの違い

似た言葉と並べると、コンテキストの役割がはっきりします。

どの「コンテキスト」かは、周りの単語で見分けられる

会議や文書で「コンテキスト」と言われたときは、一緒に出てくる単語で分野が分かります。

プログラミングのコンテキスト（実行コンテキストと this）

JavaScript では、コードが実行されるときの環境を実行コンテキスト（execution context）と呼びます。変数の見える範囲（スコープ）と this の値がその中に入っています。MDN の説明では、this の値は関数が「どこで定義されたか」ではなく「どう呼び出されたか」で決まります（アロー関数は例外）。

呼び方で this が変わる様子を動かす

同じ hello 関数を、呼び方だけ変えて実行しました（ES モジュールなので厳格モード）。

const user = {
  name: "sato",
  hello() { return `hello, ${this.name}`; },
  arrow: () => typeof this,
  later() {
    setTimeout(function () { console.log("5:", typeof this, this.constructor.name); }, 0);
    setTimeout(() => console.log("6:", this.name), 0);
  },
};
console.log("1:", user.hello());
const f = user.hello;
try { f(); } catch (e) { console.log("2:", `${e.name}: ${e.message}`); }
console.log("3:", f.call({ name: "suzuki" }));
console.log("4:", user.hello.bind({ name: "tanaka" })());
console.log("7:", user.arrow());
class Btn { constructor() { this.label = "OK"; } onClick() { return this.label; } }
const h = new Btn().onClick;
try { h(); } catch (e) { console.log("8:", `${e.name}: ${e.message}`); }
user.later();

1: hello, sato
2: TypeError: Cannot read properties of undefined (reading 'name')
3: hello, suzuki
4: hello, tanaka
7: undefined
8: TypeError: Cannot read properties of undefined (reading 'label')
5: object Timeout
6: sato

2番と8番の Cannot read properties of undefined が、this のコンテキストを失ったときの典型のエラーです。 React のクラスコンポーネントやイベントハンドラーにメソッドを渡したときに起きやすく、bind するかアロー関数で包むと直ります。厳格モードでないファイル（CommonJS で "use strict" なし）では、同じ f() がエラーにならず this が globalThis になり、undefined を返しました。エラーにならない分、気づきにくくなります。

bind・call・apply の使い分けは、関連記事「JavaScript thisとは？早見表とbind・call・apply」で扱っています。

Go の context.Context（タイムアウト・キャンセル）

Go 公式のドキュメントでは、context パッケージは「期限・キャンセルの合図・リクエスト単位の値を、API の境界やプロセスをまたいで運ぶ Context 型」を定めています。Go で ctx と書かれていたら、ほぼこの context.Context です。

親から子へ context をつないでいくと、親を止めたときに子もまとめて止まります。

flowchart TD
    A[Background<br>大元] --> B[WithCancel<br>親]
    B --> C[WithTimeout<br>子 1時間]
    C --> D[DB問い合わせ]
    C --> E[外部API呼び出し]

タイムアウト・キャンセル・理由・値を動かす

package main

import (
    "context"
    "errors"
    "fmt"
    "time"
)

type key string

func slowJob(ctx context.Context, d time.Duration) error {
    select {
    case <-time.After(d):
        return nil
    case <-ctx.Done():
        return ctx.Err()
    }
}

func main() {
    // 1. タイムアウト
    ctx, cancel := context.WithTimeout(context.Background(), 100*time.Millisecond)
    defer cancel()
    start := time.Now()
    err := slowJob(ctx, 2*time.Second)
    fmt.Printf("1: err=%v elapsed=%dms deadlineExceeded=%v\n", err, time.Since(start).Milliseconds(), errors.Is(err, context.DeadlineExceeded))

    // 2. キャンセル（親を止めると子も止まる）
    parent, stop := context.WithCancel(context.Background())
    child, cancelChild := context.WithTimeout(parent, time.Hour)
    defer cancelChild()
    go func() { time.Sleep(50 * time.Millisecond); stop() }()
    start = time.Now()
    err = slowJob(child, 2*time.Second)
    fmt.Printf("2: err=%v elapsed=%dms\n", err, time.Since(start).Milliseconds())

    // 3. 理由つきキャンセル
    c3, cancel3 := context.WithCancelCause(context.Background())
    cancel3(errors.New("user closed the tab"))
    fmt.Printf("3: err=%v cause=%v\n", c3.Err(), context.Cause(c3))

    // 4. 値（リクエストID）
    c4 := context.WithValue(context.Background(), key("requestID"), "req-261")
    fmt.Printf("4: requestID=%v missing=%v\n", c4.Value(key("requestID")), c4.Value(key("user")))

    // 5. 間に合う場合
    c5, cancel5 := context.WithTimeout(context.Background(), time.Second)
    defer cancel5()
    fmt.Printf("5: err=%v\n", slowJob(c5, 10*time.Millisecond))
}

1: err=context deadline exceeded elapsed=100ms deadlineExceeded=true
2: err=context canceled elapsed=50ms
3: err=context canceled cause=user closed the tab
4: requestID=req-261 missing=<nil>
5: err=<nil>

• 1：2秒かかる処理が、期限の 100ms で止まりました。エラーは context deadline exceeded
• 2：子の期限は1時間でしたが、親を 50ms で止めると子も止まりました。エラーは context canceled
• 3：WithCancelCause（Go 1.20 から）で、止めた理由を context.Cause で取り出せます
• 4：WithValue の値は、無いキーなら nil です

HTTP サーバーでは、接続が切れると r.Context() が止まる

net/http のハンドラーでは、r.Context() がそのリクエストのコンテキストです。3秒かかる処理を持つサーバーを立て、curl -m 1（1秒で打ち切り）で呼んだときのサーバーのログです。

http.HandleFunc("/report", func(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    start := time.Now()
    select {
    case <-time.After(3 * time.Second):
        fmt.Fprintln(w, "done")
        log.Printf("finished in %v", time.Since(start).Round(time.Millisecond))
    case <-ctx.Done():
        log.Printf("stopped after %v: %v", time.Since(start).Round(time.Millisecond), ctx.Err())
    }
})

$ curl -sS -m 1 http://127.0.0.1:26101/report
curl: (28) Operation timed out after 1001 milliseconds with 0 bytes received
$ curl -sS http://127.0.0.1:26101/report
done

（サーバーのログ）
2026/10/17 21:06:14 stopped after 1.001s: context canceled
2026/10/17 21:06:18 finished in 3.014s

利用者が接続を切った時点で、サーバー側の処理も止められます。 ctx を DB や外部 API の呼び出しにも渡しておくと、誰も待っていない処理を続けずに済みます。

cancel を呼び忘れると go vet が警告する

WithTimeout が返す cancel を捨てると、go vet が次のように知らせます。

ctx, _ := context.WithTimeout(context.Background(), time.Second)

./main.go:9:7: the cancel function returned by context.WithTimeout should be called, not discarded, to avoid a context leak

Go 公式のドキュメントにある使い方の決まりは次のとおりです。

WithDeadline や errgroup との組み合わせは、関連記事「Go contextの使い方｜WithTimeout・WithCancel入門」で扱っています。

React Context（props を渡さずに値を届ける）

React の Context は、親コンポーネントの値を、途中のコンポーネントに props を書かずに子孫へ届ける仕組みです。React 公式のドキュメントでは、useContext を呼んだコンポーネントは「上位かつ最も内側にある Provider の value」を受け取り、Provider が無いときだけ createContext の既定値が使われます。

import { createContext, useContext, createElement as h } from "react";
import { renderToString } from "react-dom/server";

const ThemeContext = createContext("light");          // 既定値

function Button() {
  const theme = useContext(ThemeContext);              // いちばん近い Provider の値
  return h("button", { className: theme }, theme);
}
function Toolbar() { return h("section", null, h(Button)); }  // props で theme を渡していない

console.log("Providerなし :", renderToString(h(Toolbar)));
console.log("dark で包む  :", renderToString(h(ThemeContext, { value: "dark" }, h(Toolbar))));
console.log("入れ子       :", renderToString(
  h(ThemeContext, { value: "dark" }, h(Toolbar), h(ThemeContext, { value: "blue" }, h(Toolbar)))));

Providerなし : <section><button class="light">light</button></section>
dark で包む  : <section><button class="dark">dark</button></section>
入れ子       : <section><button class="dark">dark</button></section><section><button class="blue">blue</button></section>

Toolbar は theme を受け取っていないのに、Button に値が届いています。入れ子では、内側の blue が優先されました。JSX なら <ThemeContext value="dark"> と書きます。React 19 からは <ThemeContext> そのものを Provider として書けて、<ThemeContext.Provider> は React 19 より前の書き方（レガシー）とドキュメントにあります。

値が変わると、その Context を読むコンポーネントがすべて描き直されます。分け方と再描画の抑え方は、関連記事「React useContextの使い方｜再レンダリング対策まで」で扱っています。

Python のコンテキスト（with・contextvars）

Python では「コンテキスト」の付く仕組みが3つあります。どれも「ある範囲の中だけ有効な前提」を扱います。

import asyncio, contextvars, decimal
from contextlib import contextmanager

# 1. コンテキストマネージャ（with）：入るときと出るときの処理を必ず対にする
@contextmanager
def opened(name):
    print(f"  enter {name}")
    try:
        yield name
    finally:
        print(f"  exit  {name}")

try:
    with opened("db-connection") as c:
        raise ValueError("boom")
except ValueError as e:
    print("  caught:", e)

# 2. contextvars：非同期タスクごとに別の値を持つ
request_id = contextvars.ContextVar("request_id", default="-")

async def handler(rid, wait):
    request_id.set(rid)
    await asyncio.sleep(wait)
    print(f"  task {rid}: request_id={request_id.get()}")

async def main():
    await asyncio.gather(handler("A", 0.02), handler("B", 0.01))
    print("  main: request_id=", request_id.get())
asyncio.run(main())

# 3. decimal のコンテキスト：計算の精度という「前提」
with decimal.localcontext() as ctx:
    ctx.prec = 5
    print("  prec=5 :", decimal.Decimal(1) / decimal.Decimal(7))
print("  default:", decimal.Decimal(1) / decimal.Decimal(7))

  enter db-connection
  exit  db-connection
  caught: boom
  task B: request_id=B
  task A: request_id=A
  main: request_id= -
  prec=5 : 0.14286
  default: 0.1428571428571428571428571429

Python 公式のドキュメントでは、状態を持つコンテキストマネージャは、並行処理で値が漏れないよう threading.local() ではなくコンテキスト変数を使うべき、とされています。__enter__・__exit__ で自作する書き方は、関連記事「Python with文の使い方｜コンテキストマネージャと__enter__」で扱っています。

OS のコンテキストスイッチ（回数を見る）

コンテキストスイッチは、CPU が実行するプロセス（スレッド）を切り替えることです。 切り替えるとき、OS はそれまでのプロセスのレジスタやプログラムカウンタ（次に実行する命令の位置）などの「実行の途中の状態」を保存し、次のプロセスの状態を読み込みます。この保存・復元される状態が、ここでいうコンテキストです。

/proc で1つのプロセスの回数を数える

Linux では /proc/<PID>/status の voluntary_ctxt_switches と nonvoluntary_ctxt_switches に、プロセスごとの回数が出ます（Linux man-pages では Linux 2.6.23 から）。Python で、処理の前後の差を数えました。

import time

def counts():
    d = {}
    for line in open("/proc/self/status"):
        if "ctxt_switches" in line:
            k, v = line.split(":")
            d[k] = int(v)
    return d

def run(label, fn):
    a = counts(); t = time.perf_counter(); fn(); b = counts()
    print(f"{label:<22} voluntary={b['voluntary_ctxt_switches']-a['voluntary_ctxt_switches']:>5}  "
          f"nonvoluntary={b['nonvoluntary_ctxt_switches']-a['nonvoluntary_ctxt_switches']:>4}  "
          f"{time.perf_counter()-t:.2f}s")

def sleepy():
    for _ in range(1000):
        time.sleep(0.001)

def busy():
    end = time.perf_counter() + 1.0
    x = 0
    while time.perf_counter() < end:
        x += 1

run("sleep(1ms) x1000", sleepy)
run("CPU loop 1s", busy)

sleep(1ms) x1000       voluntary= 1000  nonvoluntary=   1  1.13s
CPU loop 1s            voluntary=    0  nonvoluntary=  18  1.00s

1ms の sleep を1000回すると、自発的な切り替えがちょうど1000回でした。 CPU を回し続ける処理では自発的な切り替えは0回で、OS に取り上げられた回数だけが増えました。CPU 2個のマシンで、CPU を回し続けるプロセスを1・2・4個同時に2秒ずつ動かすと、1プロセスあたりの非自発的な切り替えは次のとおりでした（同じマシンでほかの処理も動いているため、値は毎回揺れます）。

processes=1 (CPU 2) nonvoluntary per process: [201]
processes=2 (CPU 2) nonvoluntary per process: [172, 159]
processes=4 (CPU 2) nonvoluntary per process: [255, 310, 274, 242]

CPU の数より多いプロセスが CPU を取り合うと、取り上げられる回数が増える傾向が出ています。

vmstat・pidstat で1秒あたりの回数を見る

マシン全体なら vmstat の cs 列（1秒あたりのコンテキストスイッチ）、プロセスごとなら pidstat -w です。1行目は起動してからの平均なので、2行目以降を見ます。

vmstat 1 4
pidstat -w -p <PID> 1 3

ほぼ何もしていないとき：

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 2  0      0 6489196  41376 1317408    0    0     0     0  445  433  2  1 97  0  0  0
 0  0      0 6489196  41376 1317432    0    0     0    32  532  482  3  1 96  0  0  0

0.1ms の sleep を繰り返すプロセスを1つ動かしたとき：

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 0  1      0 6480568  43100 1317804    0    0  1088    12 6901 13338  5  3 45 46  1  0
 0  1      0 6478052  43384 1317820    0    0   284     0 6357 12190  4  3 47 46  1  0

1ms の sleep を繰り返すプロセスを pidstat -w で見たとき（cswch/s が自発的、nvcswch/s が非自発的）：

21:07:04      UID       PID   cswch/s nvcswch/s  Command
21:07:05        0      4027    884.00      1.00  python3
21:07:06        0      4027    886.00      0.00  python3
21:07:07        0      4027    846.00      1.00  python3
Average:        0      4027    872.00      0.67  python3

cswch/s が多いのは「待ちが多い」、nvcswch/s が多いのは「CPU の取り合いが多い」というのが読み方の目安です。 スレッドを CPU の数より大幅に増やすと、切り替えの保存・復元にかかる時間が増えます。

生成AIのコンテキストウィンドウ（トークン数を数える）

生成AIの「コンテキスト」は、モデルが1回の応答を作るときに参照できる情報すべてです。Anthropic のドキュメントでは、コンテキストウィンドウは「応答そのものを含め、モデルが応答を作るときに参照できるテキストすべて」で、学習に使ったデータとは別の「作業用の記憶」と説明されています。

上限は文字数ではなくトークン（モデルが文章を区切る単位）で数えます。同じドキュメントによると、コンテキストに入るのは次のものです。

主なモデルの上限（2026年10月17日時点）

各社の公式ドキュメントのモデル一覧の値です。

日本語と英語でトークン数はどれくらい違うか

OpenAI のトークナイザー（文章をトークンに分ける仕組み）の JavaScript 版 js-tiktoken で、同じ意味の文などを数えました。o200k_base は新しい GPT 系、cl100k_base はそれより前の GPT 系が使う方式です。

import { getEncoding } from "js-tiktoken";
const samples = {
  "日本語の文": "コンテキストとは、処理や会話の「前提となる情報」のことです。",
  "英語の文": "Context is the information that a process or conversation depends on.",
  "Pythonコード": "def add(a, b):\n    return a + b\n",
  "JSON": '{"id": 261, "name": "context", "tags": ["ai", "go"]}',
  "数字": "2026年10月17日 12345678",
};
for (const name of ["o200k_base", "cl100k_base"]) {
  const enc = getEncoding(name);
  console.log(`== ${name}`);
  for (const [k, s] of Object.entries(samples)) {
    console.log(`${k} chars=${[...s].length} tokens=${enc.encode(s).length}`);
  }
}
const enc = getEncoding("o200k_base");
const s = samples["日本語の文"];
console.log("split:", enc.encode(s).map(t => JSON.stringify(enc.decode([t]))).join(" | "));

日本語の文は、次のように区切られました。

split: "コン" | "テ" | "キ" | "スト" | "とは" | "、" | "処" | "理" | "や" | "会" | "話" | "の" | "「" | "前" | "提" | "とな" | "る" | "情報" | "」の" | "こと" | "です" | "。"

英語は69文字で12トークン（約5.8文字で1トークン）、日本語は30文字で22トークン（約1.4文字で1トークン）でした。 同じ内容なら、日本語のほうがコンテキストを多く使います。コードと日本語が混ざったこのブログの技術記事1本（約2.4万字）を数えると、12,177 トークン（約2.0文字で1トークン）でした。

トークンの区切り方はモデルの会社ごとに違うため、Claude や Gemini では同じ文でも数が変わります。正確な数は、各社の API（Anthropic ならトークンを数える API、usage 欄）で確かめます。

上限を超えるとどうなるか

Anthropic のドキュメントによると、入力だけで上限を超えると、API は 400 の invalid_request_error で prompt is too long を返します。Claude 4.5 以降のモデルでは、入力と max_tokens の合計が上限を超えるだけなら受け付け、生成の途中で上限に達すると stop_reason: "model_context_window_exceeded" で止まります。

また、同じドキュメントには、トークン数が増えるほど正確さと思い出す力が落ちる（context rot）とも書かれています。上限に収まっていても、関係の無い情報を入れすぎると答えの質が下がります。

コーディングエージェントでのコンテキスト管理

Claude Code のようなコーディングエージェントは、読んだファイルやコマンドの出力をすべてコンテキストに積んでいきます。Claude Code の公式ドキュメントでは、/context で何がコンテキストを埋めているかを表示し、/compact でそれまでの会話を要約して空きを作り、/clear で空のコンテキストから新しい会話を始めます。

使用率を下げる具体的な方法は、関連記事「Claude Codeのトークン節約術｜コンテキスト使用率を下げる7つの方法」で扱っています。調べ物を別のコンテキストに任せる方法は、関連記事「Claude Codeサブエージェントの使い方｜実測で見る委任とコンテキスト節約」で扱っています。

設計の「境界づけられたコンテキスト」（DDD）

ドメイン駆動設計（DDD：業務の言葉と構造をそのままソフトウェアの設計に写す考え方）では、境界づけられたコンテキスト（Bounded Context）という言葉を使います。Martin Fowler の解説では、大きなシステムの業務モデルを1つに統一するのは現実的ではないため、システムを複数のコンテキストに分け、それぞれの中では矛盾のないモデルを持ち、コンテキストどうしの関係を明示する、とされています。

同じ「商品」という言葉でも、部門によって必要な中身が違います。

1つの Product クラスに全部を詰めると、どの部門の変更でもそのクラスを触ることになります。コンテキストごとに別のモデルにし、境界で ID などを使って対応づけると、変更の影響が1つのコンテキストの中に収まります。マイクロサービスを分ける単位の候補として、よく使われる考え方です。

システムの外側との関係を描く「コンテキスト図」も、同じく「どこまでが対象か」を示す図です。

そのほかの「コンテキスト」（メニュー・kubectl・CSS）

Kubernetes 公式のドキュメントでは、kubeconfig の context は「アクセスのためのパラメーターを使いやすい名前でまとめるもの」で、各 context は cluster・namespace・user の3つを持ち、kubectl は current context の設定でクラスターと通信します。本番と検証のクラスターを context で切り替えている場合、今どの context かを kubectl config current-context で確かめてから操作すると、取り違えを防げます。

よくあるエラーと原因

この記事で動かした中で出たエラーと、ドキュメントに書かれているエラーをまとめました。

React で Provider の外から useContext を呼んでもエラーにはならず、既定値（今回は light）が黙って使われました。「値が変わらない」ときは、呼んでいるコンポーネントが Provider の内側にあるかを先に確かめます。

よくある質問

Q. コンテキストとは何ですか？ A. 処理や会話が正しく動くための「前提となる情報」のことです。プログラムなら this や期限、OS なら実行途中の状態、生成AIなら入力全体を指します。冒頭の早見表に分野別の意味をまとめています。

Q. コンテキストの意味を一言でいうと？ A. 英語では「文脈・前後関係」です。IT では「その処理が前提にしている情報のまとまり」と考えると、どの分野の使い方にも当てはまります。

Q. IT のコンテキストとプログラミングのコンテキストは違いますか？ A. 考え方は同じで、中身が違います。プログラミングでは JavaScript の実行コンテキストや Go の context.Context など、言語ごとに持つものが決まっています。「どの「コンテキスト」かは、周りの単語で見分けられる」の表で判断できます。

Q. コンテキストスイッチとは？ A. CPU が実行するプロセスやスレッドを切り替えることです。Linux では vmstat の cs 列や pidstat -w、/proc/<PID>/status で回数を見られます。

Q. コンテキストウィンドウとは？ A. 生成AIのモデルが1回の応答で参照できる量の上限で、トークンで数えます。2026年10月17日時点の主なモデルは100万トークン前後です。出力もこの枠に含まれます。

まとめ

• コンテキストは「処理が前提にしている情報のまとまり」。分野ごとに中身が違う。
• JavaScript の this は呼び方で決まり、取り出して呼ぶと Cannot read properties of undefined になった。
• Go の context は期限・キャンセル・値を運び、親を止めると子も止まった。HTTP の接続切れでも context canceled になった。
• React Context は最も近い Provider の値を返し、Provider が無いと既定値になった。
• コンテキストスイッチは CPU の切り替え。1ms の sleep 1000回で自発的な切り替えが1000回だった。
• 生成AIのコンテキストウィンドウはトークンで数え、日本語は英語よりトークンを多く使った。出力も同じ枠に入る。
• DDD の境界づけられたコンテキストは、1つの言葉が1つの意味で通じる範囲。

参考・出典

確認日はいずれも 2026年10月17日です。

• MDN Web Docs「this」：https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/this
• Go Packages「context」：https://pkg.go.dev/context
• React「createContext」：https://ja.react.dev/reference/react/createContext
• Python ドキュメント「contextvars --- コンテキスト変数」：https://docs.python.org/ja/3/library/contextvars.html
• Linux man-pages「proc_pid_status(5)」：https://man7.org/linux/man-pages/man5/proc_pid_status.5.html
• Claude Docs「Models overview」：https://platform.claude.com/docs/en/models/overview
• Claude Docs「Context windows」：https://platform.claude.com/docs/en/build-with-claude/context-windows
• OpenAI「Models」：https://developers.openai.com/api/docs/models
• OpenAI「GPT-6.1 Sol」：https://developers.openai.com/api/docs/models/gpt-6.1-sol
• Google AI for Developers「Gemini models」：https://ai.google.dev/gemini-api/docs/models
• Google AI for Developers「Gemini 4 Argon」：https://ai.google.dev/gemini-api/docs/models/gemini-4-argon
• Google AI for Developers「Gemini 3.8 Flash」：https://ai.google.dev/gemini-api/docs/models/gemini-3.8-flash
• Claude Code Docs「Commands」：https://code.claude.com/docs/en/commands
• Kubernetes「kubeconfigファイルを使用してクラスターアクセスを整理する」：https://kubernetes.io/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig/
• Martin Fowler「BoundedContext」：https://martinfowler.com/bliki/BoundedContext.html
• js-tiktoken（npm）：https://www.npmjs.com/package/js-tiktoken

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。