結論:商社の市況レポート作成は、Claude Code を「データ収集の補助」「テンプレ整形」「相関メモの叩き台作成」に限定して使うと、レポート1本あたりの作成時間を体感で40〜60%圧縮できる。ただし最終的な需給判断・価格予想・取引意思決定は必ずトレーダーとリスク管理部門が行う前提を崩してはならない。
要点3つ
- IEA・USDA・LME・SHFE・CME などの公開データ取得を Claude Code の
Bash+Read+WebFetchツールで半自動化する - 社内顧客(営業・トレーダー・経営陣)別の出力テンプレートを
.claude/templates/に置いて再利用する - 為替・原油・株価の相関分析は「メモの叩き台」までで止め、相場判断には使わない
対象読者:総合商社・専門商社のリサーチ部門、トレーディング部門のミドルオフィス、市況メモを毎日書いている若手アナリスト、コモディティ系の市況サービス提供企業のエンジニア
今日読めること:Claude Code を市況レポートのパイプラインに組み込むための5つのコピペ可能プロンプト、3つの典型的失敗事例(❌/⭕で比較)、ツールの限界と人間が必ず担保すべき領域
はじめに:朝6時半の市況メモが終わらなかった話
商社のリサーチ部門に在籍していた知人(20代後半・非鉄金属担当)から、こんな相談を受けたことがあります。
「朝5時に起きて、LMEの引け値、SHFEの夜間取引、ドル円、原油WTI、関連株(主要マイナー4社)を全部拾って、社内向け市況メモに整形している。整形だけで毎日90分かかる。トレーダーがデスクに座る7時20分までに出さないと意味がないので、本当に分析する時間がない」
これ、商社・コモディティ専門商社・地金商社・穀物商社・エネルギー専門会社のリサーチ職なら、誰でも一度は通る悩みだと思うんです。市況メモは「速報性」と「網羅性」が命なのに、整形作業に時間を取られて、肝心の解釈に頭が回らなくなる。
正直に言うと、Claude Code はこの問題を「半分くらい」解決します。残りの半分は人間がやらないといけない。けれど、その「半分」の効率化が、朝の90分を40分にしてくれるなら、十分価値があります。
この記事では、私が複数の商社・トレーディングハウスのリサーチ部門・ミドルオフィスの方と話して整理した「Claude Code を市況レポート業務にどう組み込むか」の実装手順を、想定シナリオベースで5つのプロンプトと、絶対にハマる3つの失敗事例とあわせて書きます。
なお、この記事は取引判断・価格予想・特定銘柄や特定コモディティの売買推奨を一切しません。Claude Code はレポート作成の補助ツールであり、相場判断は必ずトレーダー・ストラテジスト・リスク管理部門が行う前提です。「相場の不確実性」を Claude Code に背負わせてはいけません。
なぜ商社の市況レポート業務はそんなに大変なのか:5つの構造的負荷
本題に入る前に、なぜ商社の市況レポート作成がこれほど時間を食うのかを、構造的に整理しておきます。「ただ数字を集めて並べるだけ」に見えるこの作業が、実際には複合的な負荷を抱えています。
負荷1:ソースが多重・多言語・多時刻に分散している
WTI は NY 取引所、Brent は ICE、LME 非鉄はロンドン、SHFE 非鉄は上海、CME 穀物はシカゴ、JKM は シンガポール基準、TTF はオランダ。各市場の取引時間がバラバラなので、「日本時間の朝6時半時点で何を取るか」を毎日判断する必要があります。さらに、ソースサイトは英語・中国語・日本語が混在しており、表記揺れ(USD vs $ vs ドル、トン vs MT vs tonne)も毎回処理する必要がある。
負荷2:即時性と網羅性のトレードオフ
営業時間が始まる前にレポートを出さないと、市況メモとしての価値は半減します。一方で「網羅しないと意味がない」というプレッシャーもある。この板挟みで、結局「全部手動で取れる範囲だけ載せる」運用になり、毎朝バタバタする。
負荷3:読み手別のフォーマット要求
トレーダーは数字だけ欲しい。営業は顧客に見せられる体裁を求める。経営層は前月比・前年比・需給イメージが欲しい。コンプラ部門は出典明記を強く要求する。同じデータから複数バージョンを作る作業が、整形時間の半分を占める。
負荷4:データの揮発性
取引所サイトは仕様変更が頻繁。URLが変わる、HTML構造が変わる、API のレート制限が変わる、表示フォーマットが変わる。スクレイピング基盤を組んでも、半年ごとにメンテが必要になる。これがエンジニアリソースを圧迫する。
負荷5:解釈責任の曖昧化
市況レポートは「事実の羅列」だけでは価値が低い。とはいえ「示唆」「見通し」を書くと、その責任を誰が取るかが曖昧になる。若手アナリストが書いた示唆が、回り回って顧客の意思決定に使われる、というリスクが常にあります。
Claude Code はこのうち、負荷1〜3の整形作業と負荷4の仕様変更耐性には強い。負荷5の解釈責任には、絶対に踏み込ませてはいけない。線引きを最初に決めておくのが肝心です。
商社の市況レポート業務とは何か:そもそも何に時間が溶けているか
まず前提を揃えます。総合商社・専門商社で日々作られている市況レポートは、ざっくり以下の3階層に分かれます。
1. 日次サマリー(モーニングノート)
毎営業日の朝6:30〜7:30頃に出るもの。前日のNY市場・夜間アジア・欧州市場の動きをまとめたもので、A4で1〜2ページ。読者はトレーダー・営業・経営層。
収録項目の例(コモディティ別に違いますが共通項):
- 主要指標の前日終値・前日比(WTI、Brent、LME銅、LME亜鉛、鉄鉱石指数、CME小麦・大豆・トウモロコシ、JKM LNG)
- 為替(USD/JPY、EUR/USD、CNY/USD、AUD/USD)
- 株式市場の主要指数(S&P 500、日経平均、上海総合)
- 主要なニュース3〜5本(コモディティ関連、地政学、需給イベント)
- テクニカル指標の簡単なメモ
2. 週次・月次の需給バランスレポート
金曜夕方や月初に出る、もう少し分析寄りの資料。社内営業部隊・大口顧客向けに展開されることもあります。需給バランス、在庫推移、輸出入統計、政府・国際機関の発表データ反映が含まれます。
3. アドホックなテーマレポート
OPEC+の会合結果、USDA穀物需給報告(WASDE)発表後、地政学イベント(中東情勢、ロシア・ウクライナ関連、南米の天候)、決算発表、中国の経済指標発表などのタイミングで、その都度作られるもの。
このうち、Claude Code で明確に効率化できるのは(1)の日次サマリー、部分的に効率化できるのが(2)のテンプレ部分、原則として人間が書くべきなのが(3)のアドホックレポートのコア部分です。
関連して、製造業のサプライチェーンリスク予測の事例も参考になります。コモディティ価格は最終的に製造業の原材料コストに跳ね返るので、ベンチマーク手法は近接しています。製造業のサプライチェーンリスク予測をClaude Codeで実装する5ステップで書いた「複数ソースの統合」の考え方は、市況レポートにもそのまま転用できます。
Claude Code で市況レポートを組み立てる全体像
具体的なプロンプトに入る前に、全体像を整理します。Claude Code を「魔法の箱」として使うのではなく、明確な工程に分解します。
工程の分解
- データ取得層:IEA、USDA、LME、SHFE、CME、JOGMEC、経産省統計、為替APIから「数値の生データ」を取りに行く
- 正規化層:取得した生データを統一フォーマット(JSON or CSV)に変換し、前日比・週次比・YoY を計算する
- テンプレ整形層:社内顧客別のテンプレ(モーニングノート用・週次需給用・営業向け要約)に流し込む
- 解釈メモ生成層:Claude が「相関の叩き台」「ニュースサマリーの叩き台」を生成する(あくまで叩き台)
- 人間の最終チェック層:アナリスト・トレーダーがコメント・判断を上書きする(ここは絶対人間)
このうち、Claude Code が単独で完結させるのは(1)〜(3)。(4)は叩き台までで止め、(5)で人間が必ず手を入れる。これが大原則です。
ディレクトリ構成の例
~/work/market-report/
├── .claude/
│ ├── settings.json
│ └── templates/
│ ├── morning_note.md # 朝の日次サマリー雛形
│ ├── weekly_balance.md # 週次需給バランス雛形
│ └── trader_brief.md # トレーダー向け短文ブリーフ
├── data/
│ ├── raw/ # APIから取得した生データ(JSON)
│ ├── normalized/ # 正規化済みデータ(CSV)
│ └── archive/ # 過去分(日付フォルダ)
├── prompts/
│ ├── 01_fetch_data.md
│ ├── 02_normalize.md
│ ├── 03_template_morning.md
│ ├── 04_correlation_memo.md
│ └── 05_trader_summary.md
└── output/
└── YYYY-MM-DD/
├── morning_note.md
└── trader_summary.md
こうやって「プロンプトを資産化」しておくと、担当者が変わっても引き継げます。商社のリサーチ部門は人事ローテーションが激しいので、属人化を避ける意味でも、プロンプトと出力テンプレを Git で管理する運用が向いています。
5つのコピペ可能プロンプト
ここからが実践編です。実際に Claude Code に投げて使えるプロンプトを5つ用意しました。コピペして自社の銘柄・コモディティに置き換えれば使えます。
プロンプト1:複数ソースからの価格データ取得
用途:IEA・USDA・取引所サイト・主要ニュース API から、当日必要な数値を一括取得する。
あなたは商社のリサーチ部門に所属するアナリストの補助役です。
以下のソースから、本日朝のモーニングノートに必要な数値を取得してください。
【対象データ】
1. 原油:WTI先物の前日終値、Brent先物の前日終値、前日比%(EIA・公式取引所サイトから)
2. LME非鉄:銅(Cu)、亜鉛(Zn)、アルミ(Al)、ニッケル(Ni)、鉛(Pb)、錫(Sn)の3ヶ月物終値、前日比%(LME公式)
3. 鉄鋼:鉄鉱石62%Fe指数(Platts IODEX または S&P Global Commodity Insights公表値)、原料炭、HRC先物
4. 穀物:CBOT小麦・大豆・トウモロコシの期近終値、前日比%
5. LNG:JKM(プラッツ)、TTF(ヨーロッパ天然ガス)スポット
6. 為替:USD/JPY、EUR/USD、CNY/USD、AUD/USD(東京クローズ基準)
【手順】
- 各ソースを WebFetch で取得し、JSON 構造で data/raw/YYYY-MM-DD/ に保存
- 取得できなかった項目は "unavailable" と明示し、欠損理由(404/タイムアウト/レート制限)も併記
- 取得時刻(JST)を必ず記録
- 当方の出力スキーマは下記とする(厳密に従うこと):
{
"fetch_timestamp_jst": "YYYY-MM-DD HH:MM:SS",
"items": [
{
"category": "crude_oil" | "lme" | "iron_ore" | "grain" | "lng" | "fx",
"ticker": "WTI" | "Cu" | ...,
"close": float | null,
"change_pct": float | null,
"source_url": "https://...",
"fetched_at_jst": "YYYY-MM-DD HH:MM:SS",
"note": "取得成功" | "API rate limit hit" | "page structure changed"
}
]
}
【重要な制約】
- 価格の「予想」「目標値」は絶対に生成しないこと
- ソースが取得できない場合は推測で埋めない
- 同じ数値を複数ソースで取れた場合は両方記録し、差分があれば note に書く
このプロンプトのポイントは「取得できなかったら推測しない」を厳格に書いている点です。Claude は親切なので、たまに「直近の傾向から推定すると…」と空気を読んで埋めようとすることがあります。市況レポートでこれをやられると致命的なので、明示的に禁止しておきます。
プロンプト2:正規化と前日比・週次比の計算
用途:生データを正規化し、前日比・週次比・YoYを計算する。
data/raw/YYYY-MM-DD/ に保存された JSON ファイルを読み込み、
以下を実行してください。
【処理】
1. 各銘柄について、前日終値、前々日終値、前週同曜日終値、前年同日終値を
data/archive/ から取得して比較する
2. 前日比%、前週比%、YoY% を計算
3. 計算結果を data/normalized/YYYY-MM-DD.csv に保存
【CSVの列】
date, category, ticker, close, change_pct_1d, change_pct_5d, change_pct_ytd, change_pct_yoy, source_url, note
【計算の制約】
- 過去データが取得できない場合は "NA" を入れる(空欄や 0 で埋めない)
- 計算式が不明確な箇所はコメントに記述
- 為替は東京クローズ基準で統一(NYクローズと混ぜない)
- 連休明けは前日比ではなく「前営業日比」とし、note 欄に営業日数を明記
【絶対にやらないこと】
- 欠損値を「直近トレンドから補完」しない
- 「異常値」と判断したデータを勝手に除外しない(必ず note 欄に「異常値の疑い」と書くだけ)
商社の市況レポートは、間違った数字を1度でも出すと信頼を失います。「異常値っぽいから外しておきました」みたいな勝手な処理は絶対NGです。Claude にも明示しておきます。
プロンプト3:モーニングノートのテンプレ整形
用途:正規化済みデータを社内向けモーニングノートのテンプレに流し込む。
data/normalized/YYYY-MM-DD.csv を読み込み、
.claude/templates/morning_note.md のテンプレに従って
output/YYYY-MM-DD/morning_note.md を生成してください。
【テンプレ構造】
# 市況モーニングノート(YYYY-MM-DD)
## 1. サマリー(3行)
- [銘柄やイベントの叩き台。「前日との差が大きかった上位3項目」を機械的に抽出]
- [叩き台のみ。「強気/弱気」などの方向感判断は書かない]
## 2. 主要価格テーブル
| カテゴリ | 銘柄 | 終値 | 前日比 | 週次比 | YoY |
## 3. 為替
[テーブル]
## 4. 当日の注目イベント(カレンダーから)
- [USDA WASDE、EIA週次在庫、Fed FOMC、OPEC+会合、中国PMI 等の予定]
## 5. ニュースヘッドライン(3〜5本、出典URL付き)
[当日朝までに出ているTier 1ソースのニュース要約]
【整形のルール】
- 価格は通貨単位を必ず明記($/bbl, $/MT, ¢/bu 等)
- 前日比%は小数1桁、太字で正は赤、負は青(社内CSSスタイル準拠)
- 「強気」「弱気」「割安」「割高」など評価語は使わない
- ニュース要約は1本100文字以内、必ず出典URLを併記
- 出典が取れないニュースは載せない
【出力後】
- 文末に "## 注意" として下記を必ず付ける:
"本資料は社内参考用の自動整形ドラフトです。最終判断は担当アナリスト・トレーダーの確認後に行ってください。価格予想・取引推奨は含まれません。"
「強気/弱気」みたいな評価語を Claude に書かせると、それを読んだ営業担当が「リサーチが弱気と言ってますよ」と顧客に伝えてしまうリスクがあります。テンプレの段階で評価語禁止にしておくのが安全です。
プロンプト4:為替・原油の相関メモの叩き台
用途:相関分析の「叩き台」を作る。最終解釈は人間。
data/normalized/ の直近30営業日分を読み込み、
以下の組み合わせについて、相関係数(Pearson)を計算してください。
【相関ペア】
- USD/JPY × WTI
- USD/JPY × LME銅
- USD/JPY × 鉄鉱石62%Fe
- WTI × LME銅
- WTI × CBOT小麦
- 上海総合 × LME銅
- S&P 500 × WTI
【出力】
output/YYYY-MM-DD/correlation_memo.md として下記構造:
# 相関メモ(過去30営業日・YYYY-MM-DD時点)
## 計算結果
| ペア | 相関係数 | 標本サイズ | p値 |
## 観察事項(機械的記述のみ)
- 相関係数 |r| が 0.7以上 のペアを列挙
- 相関係数の符号が直近5営業日と過去30営業日で反転している場合に指摘
- ただし「だから今後こうなる」とは書かない
## 注意書き
- 相関は因果ではありません
- 30営業日は短期の参考値で、構造的関係を示すものではありません
- 取引判断には使わないでください
【絶対NG】
- 「したがって今後は」「示唆される」などの予測表現
- 「相関が高いから順張り戦略が機能する」など投資助言的表現
- 短期サンプルから恒久的傾向を語ること
相関分析は、Claude Code に投げると非常に流暢な「示唆」を書いてくれます。けれど、商社の市況メモで Claude の文章を「示唆」として読まれると、後で大問題になります。「叩き台」「機械的記述のみ」「予測禁止」を3点セットで明示するのが、相関プロンプトの肝です。
プロンプト5:トレーダー向け超短文サマリー
用途:トレーダーが朝デスクに座る前に5秒で読める、超圧縮版サマリー。
output/YYYY-MM-DD/morning_note.md を読み込み、
トレーダー向けの超短文サマリーを生成してください。
【条件】
- 全体で300文字以内
- 構造は3ブロック:
1. 前日大きく動いた銘柄上位3つ(銘柄、前日比%のみ)
2. 当日の主要イベントカレンダー(時刻+イベント名)
3. Tier 1ソースで報道された地政学・需給に関わるニュース最大2本(出典URL併記)
- 評価語(強気/弱気/上昇期待 等)は禁止
- 数字は太字、出典URLは末尾にまとめる
【出力先】
output/YYYY-MM-DD/trader_summary.md
【末尾必須文】
"これは自動整形ドラフトです。最終判断はトレーダー・リスク管理部門が行ってください。"
トレーダー向けのサマリーは、商社のリサーチ業務で一番ニーズが大きい成果物です。読み手は時間がない、評価語は不要、数字と出典だけ欲しい、というニーズに合わせます。
【要注意】商社の市況レポート × Claude Code で必ずハマる失敗パターン
ここからが、実装する前に絶対に知っておいてほしい部分です。Claude Code は強力ですが、市況レポートという文脈では「気の利いた振る舞い」が逆効果になることがあります。私が複数の現場で見たり聞いたりした失敗パターンを3つ、❌(やりがち)と⭕(正解)で書きます。
失敗1:価格予想を Claude に書かせてしまう
❌ やりがちな例
# プロンプト(NG例)
WTIの直近30日の値動きから、今週の価格レンジを予想してください。
強気/弱気のシナリオも併せてください。
これは絶対NGです。Claude は流暢な「予想」を書いてくれますが、その予想には何の根拠もありません。学習データの中にあった過去の市況コメンタリーを織り交ぜて、それっぽく見える文章を生成しているだけです。これを読んだ営業や経営層が「リサーチが今週強気と言ってる」と受け取って意思決定したら、責任問題になります。
⭕ 正しい使い方
# プロンプト(OK例)
WTIの直近30日の値動きを以下のフォーマットでテーブル化してください。
- 日付、終値、前日比%、出来高
価格予想・レンジ予想・方向感のコメントは一切しないでください。
解釈・予想は当方アナリストが行います。
Claude にやらせるのは「過去の事実の整理」までで止める。未来予測は人間にしか書けない(正確には、人間でも当たらないが、責任を負う主体がはっきりしている)。これを徹底すると、Claude Code の使い道が一気にクリアになります。
失敗2:取得できなかったデータを「推測補完」させてしまう
❌ やりがちな例
LME公式サイトがメンテナンスでアクセスできなかった日、Claude にデータ取得を任せていたら、レポートに普通に「LME銅 $9,420 (前日比 +0.3%)」と書いてあった。後で確認したら、実際の数値とは数十ドル違っていた。Claude が「直近トレンドからの推定値」を勝手に埋めていた。
⭕ 正しい対策
プロンプト1で書いた通り、「取得できなかったら推測しない」を必ず明示し、欠損理由(404・タイムアウト・レート制限・サイト構造変更)を note に書かせる。さらに、出力テンプレ側でも「unavailable」と明記される設計にする。
運用面では、欠損データが出たときに Slack 通知を飛ばす Hook を入れておくと、担当アナリストが手動で確認できます。「Claude が自動で埋めてくれた」を信頼しない運用設計が必須です。
失敗3:相関分析を「示唆」として社内配信してしまう
❌ やりがちな例
「USD/JPY と WTI の30日相関が +0.72 なので、円安局面では原油も連動上昇する傾向が示唆されます」と Claude が書いてしまい、それをそのまま営業部に転送してしまった。営業部はそれを「リサーチからの示唆」として顧客に話してしまい、後でクレームに繋がった。
⭕ 正しい対策
相関プロンプト(プロンプト4)で書いた通り、「相関は因果ではない」「だから今後こうなるとは書かない」を明示し、出力フォーマット上も「観察事項(機械的記述のみ)」と区切る。配信前に必ず人間がレビューし、評価語が混ざっていないかチェックする運用にする。
金融機関での類似の論点については、金融機関のリスク計算(VaR)実装をClaude Codeで補助する事例でも書きました。VaRも市況の相関と同じく「過去の数値から未来を語ること」の限界がつきまといます。商社の市況メモも金融機関のリスクメトリクスも、最終解釈は人間という構造は共通です。
失敗4(おまけ):社内顧客別のテンプレを統一しすぎて使われなくなる
❌ やりがちな例
「全社統一テンプレ」を作ったら、トレーダーは「長すぎる」、経営層は「数字ばかりで読みにくい」、営業は「専門用語が多い」と全方位から不満が出て、結局誰も使わなくなった。
⭕ 正しい対策
テンプレは必ず読み手別に分ける。プロンプト3(モーニングノート)、プロンプト5(トレーダー向け超短文)を別建てにしたのは、まさにこの理由です。営業向けはさらに別テンプレを作る。経営層向けは月次サマリーだけにする、など、用途別に整理します。Claude Code の .claude/templates/ に置いておけば、テンプレ自体が資産になります。
コモディティ別の実装上の注意点
「コモディティの市況レポート」と一口に言っても、扱う商品によって取得すべきソース・気をつけるべき点が違います。代表的なカテゴリ別に、Claude Code を使うときの実装上のコツを書きます。
原油・石油製品
WTI(NYMEX)、Brent(ICE)、ドバイ、JCC(日本のクルードコスト平均)、ガソリン・軽油・ジェット燃料のクラックスプレッド。OPEC+の会合スケジュール、EIA週次在庫(毎週水曜23時)、API週次在庫(毎週火曜)、IEA月報、OPEC月報の発表タイミングは固定なので、カレンダー化しておきます。Claude には「次の主要発表が何日後か」をテーブル化させると便利。
注意点として、原油の価格差(WTI – Brent スプレッド、Brent – ドバイ スプレッド)は地政学要因の影響を強く受けます。Claude に「なぜ広がったか」を聞いても、表面的な答えしか返ってこないので、解釈は人間が担当します。
LME 非鉄金属
銅・亜鉛・アルミ・ニッケル・鉛・錫の3ヶ月物が主軸。LMEは正午前後にオフィシャル価格を公表します。中国の祝日(春節・国慶節)中はSHFE取引停止で動きが鈍るので、カレンダーに祝日を入れておきます。在庫データ(LME・SHFE・COMEX)は毎営業日公表されるので、Claude に「在庫の前日比 +5% 以上の変化」を機械的に抽出させると、人間が見るべき箇所が絞れます。
鉄鋼・鉄鋼原料
鉄鉱石は Platts IODEX、原料炭は Platts、鉄スクラップは複数指標(米中日でバラバラ)、HRC(熱延コイル)は中国・米国・欧州で別々の先物市場。中国の建設業活動・不動産デベロッパーの財務状況が鉄鋼需給を大きく動かすので、中国マクロ指標(PMI、不動産販売、固定資産投資)とのセット取得が欠かせません。
穀物・大豆
CBOT(小麦・大豆・トウモロコシ・大豆ミール・大豆油)、WASDE(毎月12日前後の23時に発表)、USDAの作付面積予想、収穫進捗、輸出販売週報。南米(ブラジル・アルゼンチン)とロシア・ウクライナ・米国の生産・輸出が主要因。気象データ(NOAA、ブラジルINMET)との組み合わせもよく使われますが、気象解釈は完全に人間領域です。
LNG・天然ガス
JKM(東アジア向けLNGスポット指標)、TTF(オランダ・欧州天然ガスハブ)、Henry Hub(米国)。冬季の暖房需要、夏季の発電需要、欧州のガス在庫水準(GIE AGSI+)、中国のLNG輸入動向が主要因。OPEC+ほど明確なカルテルがない分、需給は産地・天候・経済活動の関数で動きます。
これらすべてに対応する「万能スクリプト」を最初から作ろうとすると失敗します。担当しているコモディティから1つずつ、プロンプトを書くのが現実的です。
運用設計:Claude Code を市況パイプラインに組み込む
5つのプロンプトを作っただけでは、実運用には乗りません。実際に毎朝動かすには、以下の運用設計が必要です。
1. スケジューラとの組み合わせ
Claude Code は対話的に使うことが多いですが、市況レポートは「毎朝決まった時刻に動く」ことが価値です。cron や macOS の launchd、あるいは Linux サーバ上の systemd timer で、決まった時刻に claude コマンドを叩くようにします。
# 例:朝6時にデータ取得 → 6時15分に整形 → 6時20分にSlack通知
# crontab -e
0 6 * * 1-5 cd ~/work/market-report && claude --print "プロンプト1の内容" >> logs/fetch.log 2>&1
15 6 * * 1-5 cd ~/work/market-report && claude --print "プロンプト3の内容" >> logs/format.log 2>&1
20 6 * * 1-5 ~/work/market-report/scripts/slack_notify.sh
当然、cron に乗せる前に「動かない日」を想定したフェイルセーフが必要です。データ取得が失敗した日、Slack に「本日のモーニングノートは自動生成に失敗しました。担当者は手動で確認してください」と通知が飛ぶようにします。沈黙=成功と解釈させないのがポイント。
2. 人間のレビューゲート
自動配信は絶対にしない。Claude Code が output/YYYY-MM-DD/morning_note.md を生成したら、まず担当アナリストの目視チェックを経由して、それから社内配信する。担当者が休みの日は配信を止める。これを「自動化されたから人を介さなくていい」と勘違いすると事故ります。
3. 監査ログの保管
Claude Code に何を投げて、何が返ってきたか、すべて Git にコミットして残します。後で「あの日のレポートはなぜこの数字だった?」「誰がいつ修正した?」を追跡できるようにします。商社のリサーチ部門は、内部監査・コンプライアンス監査の対象になることもあるので、ログは資産です。
4. Tier 1 ソース原則
市況レポートで参照するソースは、必ず一次ソースまたは Tier 1 のメディアに限定します。SNSやまとめサイトの情報を Claude にスクレイピングさせて、それをレポートに載せるのは厳禁です。プロンプト1の WebFetch で叩く URL は、IEA、USDA、LME、SHFE、CME、Bloomberg、Reuters、Wall Street Journal、Financial Times、日経QUICK、JOGMEC、経産省統計などに限定します。
金融犯罪調査の領域でもソースの信頼性は最重要論点で、金融機関のAML(マネロン)調査をClaude Codeで自動化する5ステップでも触れた通り、「どのソースから取った情報か」を100%トレースできる設計にしておくと、後の検証コストが激減します。
導入ロードマップ:小さく始めて段階的に拡張する
いきなり全部組まないこと。商社のリサーチ部門で Claude Code を導入する場合、以下の順序が現実的です。
Phase 1(1週目):手動オペレーションの記録
まず、現状の市況レポート作成オペレーションを、メンバー全員に「何時に何をしているか」を15分単位で書き出してもらう。Claude Code 導入の前に、現状の「人間の動き」を可視化します。
Phase 2(2〜3週目):プロンプト1〜3 を導入
データ取得(プロンプト1)、正規化(プロンプト2)、モーニングノート整形(プロンプト3)を試験的に導入。最初は人間のチェックを必ず2回(担当者+チーフ)入れます。出力結果と人間が書いたレポートを比較し、差分をプロンプトに反映します。
Phase 3(4〜5週目):プロンプト4〜5 を追加
相関メモ(プロンプト4)とトレーダー向け超短文(プロンプト5)を追加。ここでも人間のレビューゲートは外しません。
Phase 4(6週目以降):運用安定化
cron での自動実行、Slack 連携、監査ログ整備、フェイルセーフを整える。担当者ローテーションを意識して、引き継ぎ手順書を README.md に残します。
Phase 5(3ヶ月以降):範囲拡張
日次サマリーで安定したら、週次需給バランスレポート、テーマレポートのアドホック部分にも拡張。ただし、アドホックレポートの「分析の核」は人間が書く前提を崩さない。Claude Code は「データ整形」「過去事例の引用」「資料化」までを担当する。
もう少し実装に踏み込んだ補足:Claude Code のツール選びのコツ
Claude Code は内部で複数のツール(Read、Write、Bash、WebFetch、Grep など)を使い分けます。市況レポートの実装で、それぞれをどう使うかのコツを書きます。
WebFetch ツールの使いどころ
WebFetch は HTTP リクエストでページを取得し、Claude が中身を要約・抽出する仕組みです。市況レポートでは「公開ページから1つの数値を取る」のに向いています。たとえば、EIA週次在庫の最新値を1つ取りたい場合、URL を渡して「在庫の前週比増減の数値だけ JSON で返して」と指示します。
注意点として、ログインが必要なページや Cloudflare 等で保護されているページは取得できません。その場合は r.jina.ai 経由(Tier 1ソースに限り)で取得を試すか、人間が代わりに取得してファイルとして渡します。
Bash ツールでのスクリプト実行
API ベースで構造化データを取りたい場合は、Python スクリプトを scripts/ 配下に置いて、Claude Code に Bash 経由で実行させます。スクリプト自体も Claude に書かせるとよいですが、本番運用に乗せる前に必ず人間がコードレビューします。「curl で叩いて結果を jq で整形」するだけの薄いラッパーを多数用意するのが、保守性の観点でおすすめです。
Read/Write の組み合わせで履歴を持つ
Claude Code は会話の中ではコンテキストを保持しますが、別セッションになると忘れます。市況レポートのように毎日同じ作業をする場合、過去のデータを data/archive/ にファイルとして残し、必要に応じて Read で読み込みます。「昨日の Cu 終値はいくらだった?」と聞かれたら、archive からファイルを読んで答えるという設計です。
Grep でアーカイブ検索
「過去30日のうち、WTIが2%以上動いた日はいつか」のような問いは、archive 内の CSV を Grep で検索すれば取れます。Claude Code の Grep は ripgrep ベースで高速なので、数百日分のアーカイブでも一瞬で返ってきます。
Slash command で運用を固める
毎日同じプロンプトを書くのは非効率なので、Claude Code の Slash command 機能で「/morning でモーニングノート生成」「/correlation で相関メモ生成」のような短縮コマンドを .claude/commands/ に登録します。これで担当者交代時の引き継ぎが楽になります。
Hooks で安全弁を入れる
Claude Code には Hooks 機能があり、特定のツール実行前後にスクリプトを差し込めます。たとえば「公開フォルダに書き込む前に内容をチェック」「Slack配信前に文字数をチェック」「禁止語(価格予想、強気/弱気)が混入していないかチェック」というガードを入れておくと、事故が減ります。
失敗事例の追加深掘り:現場で実際に起きた4つの事故
先ほどの3つの主要失敗パターンに加えて、現場で実際に起きた事故をもう少し追加します。これらは Claude Code 固有というよりは「AIツールを市況業務に組み込むとき全般」の話ですが、Claude Code でも同じ落とし穴があります。
事故A:タイムゾーンの混在
NY時間の引け値、ロンドンの正午オフィシャル、東京の15時引け、シンガポールの夕方の気配、シカゴの夜間取引。それぞれを「同じ前日比」として並べたら、社内で「数字が合わない」と指摘された。Claude にデータ取得を任せていたら、ソースごとに異なるタイムゾーンの値が混在していた。
対策:プロンプトの中で「すべて日本時間 6:00 時点での最新確定値を取る」「先物の場合は前営業日終値を採用」「為替は東京クローズで統一」というルールを明示的に書く。タイムゾーン情報も JSON のメタデータに必ず入れる。
事故B:単位の不統一
原油は バレル($/bbl)、LNGは MMBtu または トン、鉄鉱石は ドライメトリックトン($/dmt)、穀物は ブッシェル(¢/bu)、非鉄は MT($/MT)。「同じ価格レンジ」として並べると、読み手が混乱します。Claude にそのまま整形させると、たまに単位を省略することがあります。
対策:出力テンプレに「単位は必ず明記」「同じカテゴリ内で単位を統一」「単位換算が必要な場合は note 欄に明記」を入れる。
事故C:出典のリンク切れ
レポート公開後、半年経ってから「あの記事の出典が見つからない」と指摘された。Claude がスクレイピングした記事URL が、その後元サイトで削除されていた。
対策:出典は URL だけでなく、取得時のタイトル・公開日・媒体名を必ずセットで記録する。重要なソースは data/archive/sources/ に取得時の HTML or テキストキャッシュも残す。Tier 1メディアは購読契約があれば永続URLがあるので、それを優先する。
事故D:Claude のバージョン更新後に挙動が変わった
Claude Code のバージョン更新後、同じプロンプトで出力フォーマットが微妙に変わり、Slack 連携スクリプトがエラーになった。Claude は基本的に互換を保ちますが、出力の細部は変わることがあります。
対策:出力の最重要部分(JSON スキーマ、テーブルのカラム順)は、プロンプトで「厳密にこの順序で」と明示する。出力後にスクリプトで構造検証(JSON Schema バリデーション等)を入れる。バージョン更新時は必ず1回手動テストする。
商社のリサーチ部門が Claude Code を「使う側」になるためのスキル
Claude Code を導入するとき、現場のアナリスト全員がエンジニアレベルのスキルを持つ必要はありません。とはいえ、最低限のリテラシーが必要です。
必要なスキル(全員)
- ターミナル(macOS の Terminal.app、Windows の WSL)で簡単なコマンドを打てる
- テキストエディタ(VS Code 推奨)で
.mdファイルを編集できる - Git の
add / commit / push / pullができる(GUI でもOK) - JSON・CSV の中身を読める
- 「プロンプトは長く書いた方が安定する」「制約条件は明示する」という基本原則を理解している
あると望ましいスキル(チームに1〜2人)
- Python の基本(
pandasで CSV 読み書き、requestsで API 叩く、json操作) - シェルスクリプト(cron、Slack Webhook、エラーハンドリング)
- VPS または社内サーバの基本操作(SSH、systemd timer)
- API 仕様書の読み方
初期はチームに1人「Claude Code 推進担当」を置いて、その人がプロンプトと運用設計を整える。残りのメンバーは「/morning を打てば朝のレポートが生成される」を使うだけ、という運用が現実的です。
Claude Code が解決しないこと(必ず人間が担うべきこと)
この記事の中で繰り返し書いていますが、改めて整理します。Claude Code に絶対に任せてはいけない領域は以下です。
- 価格予想・レンジ予想:相場は予想を裏切るのが仕事。Claude の「示唆」は学習データの織り交ぜに過ぎない
- 需給判断・在庫評価:数値の整理は補助できても、「在庫が多いから売られる」は文脈依存。最終判断は人間
- 地政学リスクの評価:中東情勢・ロシア情勢・南米天候・米中通商などのインパクト評価は、人間の知見・センスが圧倒的に必要
- 取引判断・推奨:絶対に Claude にやらせない。これはトレーダー・リスク管理部門の専権事項
- 顧客への助言:営業が顧客に「リサーチがこう言ってる」と伝えるとき、その「リサーチ」が Claude の出力だと顧客への背信になる
- 異常値の判定:Claude は「外れ値っぽい」と気づくが、それが市場異変の予兆か単なるノイズかの判断は人間
逆に言うと、Claude Code が得意なのは:
- 定型作業(データ取得・整形・テーブル化)
- テンプレ整形(社内顧客別の出力フォーマット変換)
- 計算(前日比・週次比・YoY・相関係数)
- 叩き台(相関メモ・ニュース要約)
- 過去事例の検索・整理(社内ドキュメントから類似事例を引いてくる)
この線引きを最初に明確にしておけば、Claude Code は商社のリサーチ部門にとって強力な助手になります。逆に、線引きを曖昧にして「AIに任せた」気分になると、必ず大きな事故が起きます。相場の不確実性は、ツールを変えても消えません。
導入後3ヶ月で見える定量効果と、見えない定性効果
Claude Code を市況レポートに組み込むと、何がどう変わるのか。複数の現場の話を総合すると、以下のような変化が観察されます。これは「導入すれば必ずこうなる」という保証ではなく、適切に運用設計した場合の傾向です。
定量効果(計測しやすい指標)
- モーニングノート作成時間:90分 → 40分前後(目安として40〜60%圧縮)。ただし「Claude が生成した内容を人間がレビューする時間」は別途必要
- レポートのカバレッジ:従来は10〜15銘柄しか網羅できなかったのが、25〜30銘柄まで安定して取得可能になる
- 担当者交代時の引き継ぎ期間:プロンプトとテンプレが Git にあるので、従来1〜2ヶ月かかった引き継ぎが2週間程度に短縮できる例もある
- 夜間・休日対応:重要イベント時の臨時レポート作成時間が短縮され、土日のヘッドラインキャッチアップが楽になる
定性効果(計測しにくいが重要な変化)
- アナリストの時間配分が「整形」から「解釈・取材・現地調査」に移る
- テンプレが Git で管理されることで、ナレッジが組織資産になる(属人化解消)
- 欠損データの可視化が進み、「いつの数字か分からない」「出典不明」というモヤモヤが減る
- 新人教育の素材が増える(Claude Code のプロンプトを読めば、市況レポートに何が必要か体系的に学べる)
逆に、誤った導入をした場合のリスクとして、「自動化されたから人手が要らない」と人員を削減してしまい、いざ Claude が止まったとき(API障害・サーバ障害・予期せぬ仕様変更)に誰も手動でレポートを書けない、という事態が起こり得ます。自動化と人員配置のバランスは、技術導入の本質的な問題です。
よくある質問(FAQ)
Q1. 自社サーバ環境で Claude Code を動かして大丈夫?機密情報が漏れない?
市況データは公開情報がメインですが、社内の取引ポジション・顧客情報は絶対に Claude API に投げてはいけません。プロンプト設計時に、ポジション情報・顧客名・契約価格は手動でマスクするか、別の社内システムで扱います。Claude Code の API 経由のデータ利用ポリシーは公式ドキュメントで都度確認してください。
Q2. データ取得のスクレイピングは法的に大丈夫?
各取引所・データプロバイダの利用規約を必ず確認してください。Bloomberg・Refinitiv・S&P Global のような有償データは、契約上スクレイピング禁止のことが多いです。有償データは公式 API 経由で取得します。公開情報のみを対象に、利用規約に沿った形で取得してください。
Q3. 担当者が変わったらどうする?
プロンプトと出力テンプレを Git で管理し、README.md に運用手順を残します。Claude Code は対話履歴も残せるので、過去の運用判断をログから追跡できます。属人化を避けるためにも、Claude Code 導入の最初から Git 管理を徹底してください。
Q4. 競合他社も同じことをやり始めたら差別化はどうする?
差別化は「データ取得・整形」ではなく「解釈・人脈・現地知見」にしか出ません。Claude Code で定型作業を圧縮した分、アナリストが現地調査・トレーダーとの対話・顧客訪問に時間を割けるようにする。これが本来のリサーチ部門の価値です。
Q5. Tier 1 のメディアと言ってるけれど、無料で全部読めるわけじゃない
WSJ・FT・Bloomberg などは有料購読が必要です。社内で法人契約していれば、ログイン状態の Cookie を使った取得設計も可能ですが、技術的にも契約上もハードルがあります。無料公開部分(ヘッドライン+リード)だけ Claude に取得させ、本文確認は人間がログインしてやる、という分担が現実的です。
Q6. 相関分析の精度はどれくらい信頼できる?
Claude Code に計算させた相関係数(Pearson)自体は数学的には正確です。問題は「相関係数の解釈」です。30営業日のサンプルサイズは構造的関係を語るには短すぎますし、短期相関は構造変化の前後で急変します。計算は信頼できるが、解釈は人間がやるという原則を崩さないでください。
著者プロフィール
佐藤傑(さとう・すぐる)。株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。100社以上の企業向けAI研修・導入支援を実施。著書『AIエージェント仕事術』(SBクリエイティブ)。SoftBank IT連載7回執筆。商社・金融機関・製造業・士業を中心に、Claude Code をはじめとした生成AIの業務組み込みを支援している。
次のアクション(3つ)
- 今週中に1つ試す:本記事のプロンプト1(データ取得)だけを社内環境で動かしてみる。10銘柄でいい。手動で書いていた朝の作業がどれだけ短縮されるか体感する
- 来月までに運用設計を固める:プロンプト1〜5を
.claude/に整理し、人間のレビューゲート・Slack通知・監査ログの3点セットを組む。Phase 2 を完了させる - 3ヶ月以内に部署横断のナレッジ共有:Claude Code で作ったテンプレ・プロンプト・運用設計を、リサーチ部門だけでなく、トレーディング・ミドルオフィス・営業企画と共有する。同じ Claude Code 基盤が、他部門の業務にも横展開できる
もし「自社の市況レポート業務に Claude Code を組み込みたいけれど、何から始めればいいか分からない」「リサーチ部門に Claude Code の社内研修をしたい」というご相談があれば、Uravation の Claude Code 個別指導・導入支援コンサルでお手伝いしています。お問い合わせフォームからお気軽にご連絡ください。
参考出典
- International Energy Agency (IEA) — Oil Market Report(月次):https://www.iea.org/topics/oil-market-report
- U.S. Department of Agriculture (USDA) — World Agricultural Supply and Demand Estimates (WASDE):https://www.usda.gov/oce/commodity/wasde
- London Metal Exchange (LME) — Metals prices and reports:https://www.lme.com/
- U.S. Energy Information Administration (EIA) — Weekly Petroleum Status Report:https://www.eia.gov/petroleum/supply/weekly/
- Anthropic — Claude Code documentation:https://docs.claude.com/claude-code
- JOGMEC — エネルギー・金属鉱物資源情報:https://www.jogmec.go.jp/
本記事は商社・コモディティ専門商社のリサーチ業務・市況メモ作成業務における Claude Code の活用想定シナリオを示したものです。具体的な価格予想・取引推奨・特定銘柄の売買アドバイスは含みません。実際の運用は、各社のコンプライアンス規定・データ利用契約・内部統制に従ってください。相場の不確実性は、ツールを使っても消えません。最終的な取引判断は必ずトレーダーおよびリスク管理部門が行ってください。
