Claude Codeステータスライン設定｜レートリミット使用率の表示方法

本記事は2026年8月時点の情報です。記事中の「Haiku」は、現行世代であるClaude Haiku 4.5（claude-haiku-4-5-20251001）を指します。

ステータスラインの基本構成と表示できる情報を整理し、rate_limitsフィールドによるレートリミット使用率の見方までを解説します。使用状況は「見える化」して初めて、ペース配分や調整ができます。

「気づいたら利用上限に引っかかって作業が止まっていた」「今どれくらい使っているのか、感覚でしか把握できていない」「チームで使っていると、組織としての消費状況が見えない」——Claude Codeを日常のコーディング業務に組み込んでいる方であれば、一度はこうした状況に心当たりがあるのではないでしょうか。

Claude Codeのステータスラインとは、プロンプト行の下部にモデル名・コンテキスト使用量・レートリミット状況を常時表示する情報バーのことです。v2.1.80で追加されたrate_limitsフィールドを設定に組み込むことで、claude.aiのPro/Maxの契約では、5時間/7日間の2つの利用枠について使用率を可視化でき、上限に達する前に作業ペースを調整できるようになります。

本記事は「Claude Code実践ガイド｜AI開発の生産性を高める運用設計」シリーズの一部です。

この記事でわかること

この記事は、Claude Codeを個人またはチームで運用している方に向けて、ステータスラインの設定方法からレートリミットの見方、スクリプトによる拡張までを順番に整理しています。

• ステータスラインの基本構成 — どの情報が、どのタイミングで表示されるのかを把握できます。
• rate_limitsフィールドの仕組み — 5h/7dの2つのウィンドウと色分けアラートの意味を理解できます。
• settings.jsonとPythonスクリプトでの拡張方法 — statusLineの指定とスクリプトの組み立てに加えて、ログ記録・通知・分析まで運用を広げる手順を確認できます。
• 他機能との役割分担と向かないケース — レートリミット表示だけでは解決できない部分と、その対処法を把握できます。

Claude Codeのレートリミット管理に課題を感じているエンジニアや、チームでのAI活用ルールを整えたい方に向けて書いています。最後まで読むと、個人利用からチーム運用まで段階的にステータスラインを設計できるようになります。

Claude Codeのステータスラインとは

ステータスラインは、Claude Codeのプロンプト行の下部に常時表示される情報バーです。モデル名・コンテキスト使用量・レートリミット状況といった運用情報を、コマンドを打たなくても一目で確認できる点が特徴です。CRMの世界では「可視化こそが改善の第一歩」とされていますが、AIツールの運用でもまったく同じ原則が当てはまります。

スプレッドシートで案件やコストを管理していると、最新の状態を確認するためにファイルを開き直したり、他の担当者の入力を待ったりする手間が発生しがちです。Claude Codeの利用状況についても同じことが起きます。使用量を都度コマンドで調べる運用では、確認するタイミング自体を忘れてしまい、気づいたときにはレートリミットに達している、という状況に陥りやすくなります。ステータスラインは、この「都度確認」という手作業を「常時表示」という仕組みに置き換えるための機能です。

表示される情報

2026年10月時点の公式仕様では、ステータスラインの中身は自分で用意したスクリプトが決めます。Claude Codeがスクリプトへ渡すJSONからモデル名・コンテキスト使用率・レートリミット使用率を取り出して整形すると、たとえば次のような1行を表示できます。

Opus | Context: 45% | 5h: 23% | 7d: 41%

数値は例です。この形は、後述する設定例（statusline.sh）が出力する1行と同じです。

この1行だけを見れば、今の作業ペースを続けてよいのか、それとも軽い作業に切り替えるべきなのかの判断材料が揃います。裏を返せば、この行を表示させないまま運用していると、判断材料そのものが手元にない状態で作業を続けることになります。

「都度確認」から「常時表示」への転換

コマンドを打って使用量を確認する運用と、ステータスラインで常時表示する運用の違いを整理すると、次のようになります。

どちらの運用でも確認できる情報自体は同じです。違いは「確認という行為を仕組みに任せられるかどうか」にあります。人が意識して確認しにいかなくても情報が目に入る状態を作っておくことが、確認漏れを防ぐ近道になります。

運用フローの中での位置づけ

ステータスラインは単独の便利機能ではなく、コンテキスト管理やコスト最適化、モデル/Effort選択といった一連の運用判断の起点にあたります。使用率という「現在地」が見えて初めて、コンテキストを圧縮するか、モデルを切り替えるか、作業を一時停止するかを判断できるようになるためです。個々の機能を単発で覚えるのではなく、ステータスラインを起点とした一連の判断フローとして捉えると、運用全体の見通しが立てやすくなります。

rate_limitsフィールドでレートリミットを表示する仕組み

v2.1.80で追加されたrate_limitsフィールドは、claude.aiのPro/Maxの契約に含まれる利用枠の消費状況を、2つのウィンドウに分けてスクリプトへ渡します。短期的な使いすぎと、週単位の消費ペースを別々の指標で追える点が、このフィールドの実務上のポイントです。なお、API（Claude Console）の従量課金や、チームで共有するAPI利用量は、この表示の対象ではありません（後述します）。

各枠の消費率はused_percentage、リセット時刻はresets_atで取り出せます。「古い使用量が少しずつ減っていく」といった動きを前提にせず、resets_atの時刻を見て、その時刻に枠が戻るものとして作業計画を立てるのが確実です。

レートリミットの可視化は「見えないコスト」を「見えるコスト」に変える第一歩です。5hウィンドウで短期的な使いすぎを検知し、7dウィンドウで週単位の消費ペースを把握することで、上限に達する前に作業ペースを調整できます。CRMの運用でも、ダッシュボードで案件数や商談の進捗を可視化することが改善の出発点になりますが、AIの利用状況管理でも考え方は変わりません。数値が見える状態を作ってはじめて、ペース配分という次の行動につながります。

5hウィンドウと7dウィンドウの使い分け

5hウィンドウは、大量のコード生成やバッチ処理を実行した直後に跳ね上がりやすい指標です。目の前の作業を続けてよいかどうかを判断する材料になります。一方7dウィンドウは、週の後半にまとめて使いすぎていないか、逆に序盤に使い切ってしまっていないかといった、週単位の配分を見直すための指標です。どちらか一方だけを見ていると、短期的な過負荷か長期的な消費ペースかを取り違えることがあるため、両方の数値をセットで確認することをおすすめします。例えば5hは緑でも7dが黄色に近づいているケースでは、その日のうちは問題なくても週全体では使いすぎに向かっている、という兆候を早めに掴めます。

色による視覚的アラート

色分けはClaude Codeが自動で行うものではなく、スクリプト側で使用率に応じて色を付ける運用です（ANSIエスケープコードで色を出せます）。次のような閾値で組んでおくと、数値を読み取らなくても、色を見るだけで対応の緊急度が判断できます。

ただし、色による判断はあくまで目安です。赤表示になった時点で慌てて対応を始めるのではなく、黄色の段階で作業の優先順位を見直しておくと、赤に達したときの影響を小さくできます。数値と色をセットで見る癖をつけておくことが、結局のところ一番シンプルな予防策になります。

settings.jsonでステータスラインを設定する

ステータスラインは、settings.jsonのstatusLineに「どのコマンドを実行するか」を指定して有効にします。Claude Codeはセッションの情報をJSONで標準入力に渡し、コマンドが出力した文字列がそのまま表示されます。表示する項目は、スクリプトの中で取り出す値で決めます。

ユーザー設定の~/.claude/settings.jsonに、次の内容を書きます。設定ファイルは厳密なJSONで、//のコメントや末尾のカンマを入れると、次回起動時に設定エラー（Settings Error）として報告されます。コードブロックの中身だけを貼り付けてください。

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh",
    "padding": 2
  }
}

設定項目とスクリプトに渡るJSON

5h/7dの枠（five_hour・seven_day）は、claude.aiのProまたはMaxの契約者に対してのみ渡され、セッションで最初のAPI応答があった後に現れます。なおrate_limitsには、Claude apps gatewayを経由している場合に支出上限を示すspend_limitも入るため、Pro/Max限定なのはあくまで5h/7dの枠です（2026年10月時点の公式仕様）。各枠は個別に欠けることがあるため、jq -r '.rate_limits.five_hour.used_percentage // empty'のように、無いときの扱いをスクリプトに書いておきます。

標準入力のJSONを読んで表示する最小のスクリプト

statusLine.commandに指定する~/.claude/statusline.shの最小例です。標準入力のJSONから値を取り出し、1行にして出力します。jqが必要です（chmod +x ~/.claude/statusline.shで実行権限を付けておきます）。

#!/bin/bash
input=$(cat)

MODEL=$(echo "$input" | jq -r '.model.display_name')
CTX=$(echo "$input" | jq -r '.context_window.used_percentage // empty' | cut -d. -f1)
FIVE=$(echo "$input" | jq -r '.rate_limits.five_hour.used_percentage // empty' | cut -d. -f1)
WEEK=$(echo "$input" | jq -r '.rate_limits.seven_day.used_percentage // empty' | cut -d. -f1)

LINE="$MODEL"
[ -n "$CTX" ] && LINE="$LINE | Context: ${CTX}%"
[ -n "$FIVE" ] && LINE="$LINE | 5h: ${FIVE}%"
[ -n "$WEEK" ] && LINE="$LINE | 7d: ${WEEK}%"
echo "$LINE"

JSONを手元で流し込むと、表示を確かめられます。rate_limitsが無いセッションでは、5h・7dの部分が省かれ、モデル名とContextだけが表示されます（context_window.used_percentageは、セッションの最初のうちは値が無いこともあります）。

echo '{"model":{"display_name":"Opus"},"context_window":{"used_percentage":45.2},"rate_limits":{"five_hour":{"used_percentage":23.5,"resets_at":1738425600},"seven_day":{"used_percentage":41.2,"resets_at":1738857600}}}' | ~/.claude/statusline.sh
# Opus | Context: 45% | 5h: 23% | 7d: 41%

最小構成から始める考え方

すべての情報を詰め込むと、かえって画面が読み取りにくくなることがあります。項目を増やしすぎると本当に見るべき情報が埋もれてしまうのと同じで、ステータスラインについても、まずはrate_limits.five_hour.used_percentageとrate_limits.seven_day.used_percentageだけを表示してレートリミットの感覚をつかみ、必要に応じてcontext_window.used_percentageを足していくといった、最小構成からのスタートをおすすめします。表示する値はスクリプトを直せば後からいつでも増やせるため、最初から全部入りにする必要はありません。

設定例どおりに組むと、ターミナルの下部、入力欄のすぐ下に次のような1行が並びます（下図）。

図の数値は、上の動作確認で流し込んだサンプルの値です。5h・7dの部分は、claude.aiのPro・Maxの契約で、セッションの最初の応答が返ったあとに表示されます。まずはこの1行に慣れてから、色分けやログ記録を足していくと、表示の意味を取り違えずに済みます。

Pythonスクリプトでステータスライン運用を拡張する

settings.jsonとスクリプトによる表示だけでも運用は始められますが、ログとして残したり、閾値を超えたときに通知したりする運用まで広げると、確認作業自体を仕組みに任せられるようになります。人が毎回ステータスラインを目視するのではなく、超過を検知したら自動で知らせる仕組みに置き換えることで、確認漏れを個人の注意力に依存させずに済みます。

個人利用で始める拡張パターン

まずは自分の使用状況を記録するところから始めるのが手をつけやすい方法です。次のスクリプトは、標準入力のJSONを読み、ステータスラインに表示し、5h/7dの値があるときだけCSVにも追記します。statusLine.commandにはpython3 ~/.claude/statusline.pyのように指定します。

#!/usr/bin/env python3
"""標準入力のJSONから使用率を取り出して表示し、CSVにも追記する"""
import csv
import json
import sys
from datetime import datetime
from pathlib import Path

LOG_FILE = Path.home() / ".claude" / "rate_limit_log.csv"

data = json.load(sys.stdin)
model = data.get("model", {}).get("display_name", "?")
ctx = data.get("context_window", {}).get("used_percentage")
limits = data.get("rate_limits", {})
five = limits.get("five_hour", {}).get("used_percentage")
week = limits.get("seven_day", {}).get("used_percentage")

parts = [model]
if ctx is not None:
    parts.append(f"Context: {ctx:.0f}%")
if five is not None:
    parts.append(f"5h: {five:.0f}%")
if week is not None:
    parts.append(f"7d: {week:.0f}%")
print(" | ".join(parts))

# 5h/7dの値があるときだけ、時刻とともに記録する
if five is not None and week is not None:
    with open(LOG_FILE, "a", newline="") as f:
        csv.writer(f).writerow([datetime.now().isoformat(), f"{five:.1f}", f"{week:.1f}"])

続いて、記録したCSVを時間帯別に集計するスクリプトです。

#!/usr/bin/env python3
"""時間帯別の使用傾向をレポート"""
import csv
from collections import defaultdict
from pathlib import Path

hourly = defaultdict(list)
with open(Path.home() / ".claude" / "rate_limit_log.csv") as f:
    for row in csv.reader(f):
        hourly[row[0].split("T")[1][:2]].append(float(row[1]))

for hour in sorted(hourly):
    avg = sum(hourly[hour]) / len(hourly[hour])
    print(f"{hour}時台: 5h枠の平均 {avg:.1f}%")

ログを蓄積し時間帯別に集計すると、自分がどの時間帯に使用率を消費しやすいかが見えてきます。バッチ処理を実行する時間帯を、使用率が低い時間帯にずらすといった調整の判断材料になります。CSVという最小限の形式にとどめておくのも、いきなり本格的な分析基盤を組まずにまず記録だけを始めるという、スモールスタートの一例です。

記録がそのまま分析の材料になる状態を作っておくことが、継続的な改善の土台になります。

チーム運用へ広げる拡張パターン

個人のログ記録に慣れてきたら、通知と組み合わせて運用を広げます。次のスクリプトは、標準入力のJSONから5h枠の使用率を読み、閾値を超えたらSlackに通知します。同じ枠（同じresets_at）では1回だけ通知するように、ファイルのロックを取ってから「通知済みか」を確かめ、送信と記録までをロックの中で行います。ステータスラインのスクリプトは更新のたびに起動されるため、ロックが無いと、ほぼ同時に起動した複数のプロセスがどちらも「まだ通知していない」と判断して重複して送ることがあります。Webhook URLはコードに書かず環境変数SLACK_WEBHOOK_URLから読みます。fcntlを使うため、macOS・Linux向けの例です。

#!/usr/bin/env python3
"""5h枠の使用率が閾値を超えたらSlackに通知（同じ枠では1回だけ・macOS/Linux向け）"""
import fcntl
import json
import os
import sys
import urllib.request
from pathlib import Path

THRESHOLD = 80.0
STATE = Path.home() / ".claude" / "notified_resets_at.txt"
LOCK = Path.home() / ".claude" / "notify.lock"
webhook = os.environ.get("SLACK_WEBHOOK_URL")  # Webhook URLはコードに書かない

five = json.load(sys.stdin).get("rate_limits", {}).get("five_hour", {})
used, resets_at = five.get("used_percentage"), five.get("resets_at")

if webhook and used is not None and resets_at is not None and used >= THRESHOLD:
    with open(LOCK, "w") as lock:
        # 同時に起動した別のプロセスとは、ここで1つずつ順番に処理する
        fcntl.flock(lock, fcntl.LOCK_EX)
        # ロックを取ってから「通知済みか」を確かめ、送信と記録までを同じロックの中で行う
        if not STATE.exists() or STATE.read_text() != str(resets_at):
            body = json.dumps({"text": f"Claude Code 5h枠の使用率が {used:.0f}% です"}).encode()
            req = urllib.request.Request(webhook, body, {"Content-Type": "application/json"})
            urllib.request.urlopen(req, timeout=10)
            STATE.write_text(str(resets_at))

ステータスラインのスクリプトから呼ぶときは、受け取ったJSONをそのまま渡します。たとえばstatusline.shの末尾に、次の1行を足します。

echo "$input" | python3 ~/.claude/notify.py >/dev/null 2>&1 &

通知されるのは、そのスクリプトを動かしている本人の5h枠です。チーム全員の消費状況を集めるものではない点には注意してください。

紹介したスクリプトの役割を整理すると、次のようになります。

Slack通知を組み込んでおくと、自分が画面を見ていない間でも閾値超過に気づけます。確認を個人の注意力ではなく仕組みに任せる形にしておくと、運用ルールを維持しやすくなります。コンテキスト管理と組み合わせることで、長時間セッションでの運用も安定しやすくなると考えられます。

コスト最適化との連携

ステータスラインの情報は、コスト最適化の判断材料としても機能します。使用率という1つの指標が、複数の運用判断につながっていく点が、この機能を単独の表示機能ではなく運用フローの一部として捉えるべき理由です。

使用率に応じた作業配分

使用率が低い時間帯には大量のバッチ処理やコード生成をまとめて実行し、使用率が高くなってきたら軽めの作業に切り替える、という配分の考え方が基本になります。

最終判断は人が行う

使用率が閾値を超えたときにモデルを自動で切り替える、あるいは処理を自動で止めるといった完全自動化も技術的には組めますが、作業の途中で強制的に処理が止まると、かえって手戻りが発生することがあります。通知や色変化で状況を知らせるところまでを自動化し、実際に作業を止めるか続けるかの最終判断は人が行う、という役割分担をおすすめします。これはAIエージェントの活用全般に言えることですが、検知や下書きまではAIに任せ、最終的な実行判断は人が行うという線引きを明確にしておくと、リスクを抑えながら仕組み化のメリットを取り込めます。

自社の開発体制に合わせた運用設計

ここまで紹介した設定や拡張スクリプトは、そのまま全部を導入する必要はありません。チームの開発スタイルや、Claude Codeをどの工程で使っているかによって、最適な設定の組み合わせは異なります。企業様によって最適な形は異なりますので、汎用的な設定を鵜呑みにするのではなく、自社の運用実態に合わせて取捨選択することをおすすめします。

個人開発とチーム開発での違い

個人でClaude Codeを使っている場合は、settings.jsonとスクリプトによる表示と、必要であればCSVログ程度でも運用が回るケースが多いと考えられます。一方、複数人で使うチームでは、5h/7dの表示は「自分の契約の枠」の消費しか映しません。組織全体の消費や、メンバーごとの偏りは、ステータスラインとは別の手段で見ます。Team/Enterpriseのプランでは管理画面の分析（利用状況のダッシュボードや、使用クレジットを有効にしたときの支出レポート）と支出上限、API（Claude Console）では「Claude Code」ワークスペースの支出上限とダッシュボードが公式に用意されています（2026年10月時点）。個人開発かチーム開発かという体制の違いだけでも、必要な仕組みの範囲は大きく変わってくる点は押さえておきたいところです。

段階的な導入ステップ

一度にすべての拡張を組み込もうとすると、設定自体が複雑になり、かえって運用が続かなくなることがあります。まずはsettings.jsonでの表示項目の確認から始めて、慣れてきたらログ記録、その後にチーム通知へと段階的に広げていくことをおすすめします。

第1段階を飛ばしていきなり第3段階の通知連携から着手すると、そもそも自分やチームがどのタイミングで使用率が上がりやすいのかという前提の理解がないまま仕組みだけが先行してしまいます。表示に慣れる→記録する→通知するという順番を守ることが、結果的に近道になります。

導入時の注意点と向かないケース

ステータスラインは使用状況を見える化する機能であり、それ自体がAPI枠を増やしたり、コード生成の効率を上げたりするわけではありません。ここは正直にお伝えしておきたい点です。導入前に知っておきたい制約と、拡張が向かないケースを整理します。

見える化だけでは作業ペースは変わらない

数値やアラートが見えるようになっても、実際に作業ペースを調整するかどうかは利用者の判断に委ねられます。赤表示が出ているにもかかわらず作業を続けてしまえば、可視化の意味は薄れてしまいます。色や数値はあくまで判断材料であり、判断して行動に移すのは人の側に残る、という前提で運用ルールを考える必要があります。

拡張スクリプトが向かないケース

Pythonスクリプトによる拡張は、CSVファイルの管理やSlack Webhookの設定など、ある程度の運用負荷を伴います。個人で単発的にClaude Codeを使う程度であれば、拡張スクリプトまで組まなくても、settings.jsonとスクリプトによる表示だけで十分なケースも多いです。仕組みを増やすこと自体が目的にならないよう、利用規模に見合った範囲を見極めることがポイントになります。

チーム利用では表示だけでは足りない

ただし、複数人で日常的にClaude Codeを使っているチームの場合は、ステータスラインの5h/7d表示だけでは「誰がどれだけ使っているか」までは見えません。表示されるのは各自の契約の枠の消費率であり、組織で共有するAPI（Claude Console）の利用量や、Team/Enterpriseの支出は別の仕組みで管理するものです。管理画面の利用状況レポートやワークスペースの支出上限などを併用しないと、結局は誰かが気づくまで偏りに気づけない属人的な運用に戻ってしまいます。まずは自社の利用規模と体制に見合った範囲から着手し、必要になったタイミングで拡張を足していく考え方が現実的です。

よくある質問

Q1. ステータスラインのレートリミット表示が赤になったらどうすればよいですか？

使用率が80%を超えて赤表示になった場合は、大量のコード生成やバッチ処理を一時停止し、resets_atで示されるリセット時刻まで待つのが基本です。その間も、軽量モデルへの切り替えや作業範囲の絞り込みで消費を抑えられます。

Q2. ステータスラインの5hウィンドウと7dウィンドウはどう違いますか？

5h（5時間）ウィンドウは、claude.aiの契約に含まれる5時間単位の利用枠の消費率で、短期的な使いすぎを検知するための指標です。7d（7日間）ウィンドウは週単位の利用枠の消費率で、週単位の消費ペースを把握できます。どちらもused_percentage（消費率）とresets_at（リセット時刻）が渡されるため、いつ枠が戻るのかを時刻で確認できます（2026年10月時点の公式仕様）。

Q3. チームメンバー間でAPI使用量の偏りを管理する方法はありますか？

ステータスラインの5h/7d表示は各自の契約の枠の消費率なので、メンバー間の偏りを見る手段にはなりません。組織の利用状況は別の手段で管理します。Team/Enterpriseのプランでは、管理画面の分析（org analytics）にある支出レポート（Spend report）で、メンバーごと・モデルごとの推定支出を確認できます。ただし、このレポートは使用クレジット（usage credits）を有効にしたときに表示され、その支出を集計するものです。席ごとの利用枠の範囲内の利用は、金額では計測されません。利用の広がり（アクティブユーザー数やセッション数）は分析ダッシュボードで確認でき、使用クレジットの支出上限は組織・グループ・個人単位で設定できます。API（Claude Console）で使っている場合は、「Claude Code」ワークスペースの支出上限とダッシュボードで管理します。個人のCSVログやSlack通知は、各メンバーが自分の消費ペースを把握するための補助として位置づけると整理しやすくなります。

Q4. ステータスラインの表示をカスタムフォーマットに変更できますか？

できます。statusLineに指定したスクリプトの出力がそのまま表示されるため、表示フォーマットはスクリプトの書き方で自由に決められます。シェルスクリプトやPythonなどで標準入力のJSONからrate_limitsの値を取り出して整形できます。

Q5. レートリミットに達した場合、作業データは失われますか？

レートリミットに達してもClaude Codeのセッションは維持され、それまでの作業データ（編集中のファイル、コンテキスト）は失われません。新しいリクエストが一時的に止まるだけなので、resets_atのリセット時刻を待てば作業を再開できます。なお、planモードも調査や計画の作成にモデルとの通信が必要なため、上限に達した状態では使えません。待てない場合は、契約によっては追加の使用クレジット（usage credits）を有効にして上限を超えて使う方法があります。設定は/usage-creditsコマンドから行います。

まとめ

ステータスラインは、レートリミットとコンテキストの使用状況を「都度確認する」対象から「常時見えている」状態に変える機能です。5h/7dの2つのウィンドウと色分けアラートで現在地を把握し、スクリプトによるログ記録・通知連携で、確認作業そのものを仕組みに任せられるようになります。

まずはsettings.jsonのstatusLineでレートリミット表示を有効化するところから始めると取り組みやすいと思います。そのうえで、次の3ステップのように段階的に運用を広げる進め方もあります。

1. settings.jsonのstatusLineにスクリプトを指定し、rate_limitsの使用率と色変化に慣れる
2. CSVログで自分の使用傾向を1〜2週間ほど記録する
3. 必要であればSlack通知を足し、チームでは組織の利用状況レポートや支出上限も併用する

Claude Codeの全コマンド一覧はClaude Codeチートシート、AI活用の全体像はAI活用完全ガイドで解説しています。

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• Claude Codeのサンドボックス設定｜ファイルシステム・ネットワークの安全な制限方法
• Claude Codeの見た目カスタマイズ｜テーマ・カラー・ステータスラインの設定方法
• Claude Code × Chatwork連携｜顧客コミュニケーションを自動化する方法