[ 広告 / PR ]

AIに長文の指示を出すと、必ず一部の指示を無視されること、ありませんか?原因は「プロンプトの構造が曖昧」だからです。本記事では、私が実務で使っている8つの構造化テクニックを実例付きで紹介します。

① セクションヘッダで分割する

# 役割 # 制約 # 入力 # 出力形式 のようにマークダウン見出しで分割すると、AIの解釈精度が上がります。

② 入出力をXMLタグで囲む

  ここに対象テキストを書く


  JSON: {"summary": "...", "keywords": [...]}

③ 制約は「禁止」より「肯定」で書く

「英語を使うな」より「日本語のみで返答せよ」の方が高精度。AIは 否定文の取り扱いが弱い ためです。

④ 例(few-shot)を最低3つ入れる

入力例 → 期待出力例 のペアを 3つ以上 並べると、フォーマットが安定します。1つだけだと「たまたまそうだった」と解釈されることがあります。

⑤ ⑥ ⑦ ⑧ も実用

• ⑤ 思考ステップを step1: ... step2: ... と明示する
• ⑥ 「考えてから答えよ」を最後に置く(chain-of-thought)
• ⑦ 出力長の上限・下限を数字で示す(例: 500-700字)
• ⑧ 失敗時の挙動を指定(「不確実なら『不明』と返す」)

まとめ

プロンプトは「会話」ではなく「仕様書」です。8つの型を組み合わせるだけで、AIの出力品質が一段上がります。

PR · DMM FX 公式

国内口座数 No.1 — DMM FX

業界最狭水準スプレッド + スマホアプリ高評価 + 最短当日取引開始
新規口座開設で 最大 300,000円 キャッシュバック中

▶ DMM FX 公式サイトで詳細

※本サイトはアフィリエイトプログラムにより収益を得ています。投資はご自身の判断・責任で。

[ 広告 / PR ]

「rebase は危険」「merge派が安全」と聞きますが、実際は使い分けです。本記事では、チームで毎日使う7つの実用rebaseパターンを示します。正しく使えば、コミット履歴は驚くほど読みやすくなります。

① 最新mainに追従する squash rebase

git fetch origin
git rebase origin/main

② 自分のコミットをまとめる interactive rebase

git rebase -i HEAD~5
# pickをsquashに変えて履歴をまとめる

③ 間違えてコミットしたファイルを除外

直前のコミットからファイルを取り消すなら git reset HEAD~ 後に再コミット。複数コミット前なら interactive rebase でedit を選び該当箇所で git restore --staged。

④ コンフリクト時の安全な解消

• git status で衝突ファイル確認
• エディタで衝突マーカー解消
• git add でステージ
• git rebase --continue で次へ
• やめるなら git rebase --abort で完全に元に戻る

⑤ ⑥ ⑦ も日常パターン

• ⑤ git rebase --autosquash で fixup を自動マージ
• ⑥ git pull --rebase をデフォルト化
• ⑦ reflog で迷子になっても元に戻れる安心感

まとめ

rebase は「履歴を直線にする道具」です。force pushする時だけ、共有ブランチでないことを確認すれば事故りません。

PR · DMM FX 公式

国内口座数 No.1 — DMM FX

業界最狭水準スプレッド + スマホアプリ高評価 + 最短当日取引開始
新規口座開設で 最大 300,000円 キャッシュバック中

▶ DMM FX 公式サイトで詳細

※本サイトはアフィリエイトプログラムにより収益を得ています。投資はご自身の判断・責任で。

[ 広告 / PR ]

Windows Terminal はデフォルトでも使えますが、少し設定するだけで作業効率が2倍になります。本記事では、私が日常的に使っている10の設定を紹介します。settings.json に貼るだけで動きます。

① 起動時に自動で複数タブを開く

"startupActions": "new-tab -p PowerShell ; new-tab -p \"Ubuntu\" ; new-tab -p cmd",

② Quake モード(Win+`でドロップダウン)

"actions": [
  { "command": { "action": "globalSummon", "monitor": "any", "dropdownDuration": 200 }, "keys": "win+`" }
]

③ タブの色をプロファイルごとに分ける

PowerShell=青、Ubuntu=オレンジ、cmd=緑のように色分けすると、タブ切り替え時の視認性が大幅に上がります。tabColorを各プロファイルに設定するだけ。

④ Ctrl+Shift+矢印で単語ジャンプ

{ "command": { "action": "moveTokenLeft" },  "keys": "ctrl+shift+left" },
{ "command": { "action": "moveTokenRight" }, "keys": "ctrl+shift+right" }

⑤ 自動コピー(選択するだけでクリップボードへ)

"copyOnSelect": true,

⑥ ⑦ ⑧ ⑨ ⑩ も同様に

• ⑥ useAcrylic: true + opacity: 80 で背景透過
• ⑦ renderingType: "auto" でフォント描画最適化
• ⑧ scrollbarState: "hidden" でスクロールバー非表示
• ⑨ antialiasingMode: "cleartype" で日本語が綺麗に
• ⑩ experimental.retroTerminalEffect: true でレトロ風(おまけ)

まとめ

Windows Terminal の真価は settings.jsonを直接編集する自由度にあります。上記10個を入れるだけで、ターミナル作業時間が体感で2倍効率化します。

PR · DMM FX 公式

国内口座数 No.1 — DMM FX

業界最狭水準スプレッド + スマホアプリ高評価 + 最短当日取引開始
新規口座開設で 最大 300,000円 キャッシュバック中

▶ DMM FX 公式サイトで詳細

※本サイトはアフィリエイトプログラムにより収益を得ています。投資はご自身の判断・責任で。

[ 広告 / PR ]

Pythonの仮想環境ツールは venv / poetry / uv の3強時代に入りました。どれが速いのか、自分の環境で実測した結果をまとめます。プロジェクト規模が大きくなるほどツール選択がコストに直結します。

テスト環境と方法

• OS: Windows 11 Pro / Python 3.12.7
• 比較対象: venv (標準), poetry 2.0, uv 0.5
• タスク: numpy / pandas / scikit-learn / requests を含む50パッケージのインストール所要時間
• 計測: 各3回実行の中央値

実測結果(中央値)

• uv: 4.8 秒 ⚡
• poetry: 47 秒
• venv + pip: 38 秒

結果として uv が圧倒的に速い ことが確認できました。Rust製のため、メタデータ解決と依存性インストールが並列化されています。pipの約8倍速、poetryの約10倍速です。

uvでの実用ワークフロー

# プロジェクト初期化
uv init my-project
cd my-project

# 依存追加 (高速)
uv add pandas scikit-learn

# 仮想環境作成と同期
uv sync

# 実行
uv run python main.py

poetryからuvへの移行コスト

pyproject.toml はほぼそのまま使えます。私が試した範囲では、poetry export -f requirements.txt | uv pip install -r -で初回移行が10分で済みました。

まとめ

• uv は Rust製で並列化、約8-10倍速い
• pyproject.toml互換なので移行コスト低い
• CIでの待ち時間削減効果が一番大きい

PR · DMM FX 公式

国内口座数 No.1 — DMM FX

業界最狭水準スプレッド + スマホアプリ高評価 + 最短当日取引開始
新規口座開設で 最大 300,000円 キャッシュバック中

▶ DMM FX 公式サイトで詳細

※本サイトはアフィリエイトプログラムにより収益を得ています。投資はご自身の判断・責任で。

[ 広告 / PR ]

1. Step1: 静的解析

linter/typecheckerでまず構文と型を検証。

2. Step2: ユニットテスト

重要関数 (ロット計算/SL計算等) は単体テストを追加。

3. Step3: ペーパートレード

DRY_RUNで数日〜数週間動作確認。

4. Step4: 少額ライブ

通常ロットの1/10程度で実環境テスト。

5. Step5: 本格運用

結果が想定範囲内なら段階的にロットを増やす。

関連サービス (公式)

Claude Code 公式 →XM Trading 公式 →

PR · DMM FX 公式

国内口座数 No.1 — DMM FX

業界最狭水準スプレッド + スマホアプリ高評価 + 最短当日取引開始
新規口座開設で 最大 300,000円 キャッシュバック中

▶ DMM FX 公式サイトで詳細

※本サイトはアフィリエイトプログラムにより収益を得ています。投資はご自身の判断・責任で。

[ 広告 / PR ]

1. セッション継続の利点

前回までの会話履歴を保持したまま再開できるため、AIに同じ前提を再説明する手間が減ります。

2. 活用シーン

1日かけて構築したロジックを、翌日続きから修正・追加する場合に有効です。

3. 注意点

前回の文脈に過度に依存したコード生成になることがあるため、要件は必ず再確認します。

関連サービス (公式)

Claude Code 公式 →

PR · DMM FX 公式

国内口座数 No.1 — DMM FX

業界最狭水準スプレッド + スマホアプリ高評価 + 最短当日取引開始
新規口座開設で 最大 300,000円 キャッシュバック中

▶ DMM FX 公式サイトで詳細

※本サイトはアフィリエイトプログラムにより収益を得ています。投資はご自身の判断・責任で。

[ 広告 / PR ]

1. In-Sample/Out-of-Sample 分割を明示

「直近6ヶ月をOOSとして除外。残りで学習し、OOSでの劣化が10%以内に収まることを目標」と指示します。

2. パラメータ感度を要求

「±10%パラメータ変動でPFが0.8倍以上を維持」を要件にすると、AIが自然と頑健性を意識します。

3. シンプルさを重視

「ハイパーパラメータは7個以下」など上限を切ると、過学習しにくい設計になります。

関連サービス (公式)

Claude Code 公式 →ConoHa for Windows Server 公式 →

PR · DMM FX 公式

国内口座数 No.1 — DMM FX

業界最狭水準スプレッド + スマホアプリ高評価 + 最短当日取引開始
新規口座開設で 最大 300,000円 キャッシュバック中

▶ DMM FX 公式サイトで詳細

※本サイトはアフィリエイトプログラムにより収益を得ています。投資はご自身の判断・責任で。

[ 広告 / PR ]

1. テンプレ1: 単一戦略

「(銘柄)で(時間足)、(指標)が(条件)のときに(方向)エントリー、SL=ATR×n、TP=ATR×m、最大同時保有X件」のような型から始めます。

2. テンプレ2: 複数銘柄横断

監視対象を列挙し、「銘柄ごとに最適パラメータを別管理」「相関の強いペアは同時保有を制限」など共通制約を明示します。

3. テンプレ3: 異常時退避

急変動時の挙動を別段落で指示すると、AIが安全側のコードを書きやすくなります。

関連サービス (公式)

Claude Code 公式 →

PR · DMM FX 公式

国内口座数 No.1 — DMM FX

業界最狭水準スプレッド + スマホアプリ高評価 + 最短当日取引開始
新規口座開設で 最大 300,000円 キャッシュバック中

▶ DMM FX 公式サイトで詳細

※本サイトはアフィリエイトプログラムにより収益を得ています。投資はご自身の判断・責任で。

[ 広告 / PR ]

1. 目的の明確化

通貨ペア・時間足・運用期間・期待リスクを最初に書き出すと、AIへの指示が短くなり再生成も減ります。

2. 制約条件の言語化

1取引あたりの最大損失・同時保有数・許容スプレッドなど、数値化できる制約を箇条書きで渡します。

3. 検証フローの先決め

AIが書いたコードはまずDRY_RUN(ペーパートレード)で動作確認する流れを最初に決めると安全です。

4. 用語の統一

AIに渡す用語(SL/TP/ロット等)は最初に定義し、会話を通じて一貫して使います。

5. 再現性の確保

プロンプトと出力をGit管理することで、後から「なぜこの実装にしたか」を追跡できます。

関連サービス (公式)

Claude Code 公式 →ConoHa for Windows Server 公式 →

PR · DMM FX 公式

国内口座数 No.1 — DMM FX

業界最狭水準スプレッド + スマホアプリ高評価 + 最短当日取引開始
新規口座開設で 最大 300,000円 キャッシュバック中

▶ DMM FX 公式サイトで詳細

※本サイトはアフィリエイトプログラムにより収益を得ています。投資はご自身の判断・責任で。

[ 広告 / PR ]

AI生成コードを Git で安全に管理する3つの習慣

最終更新: 2026-05-05

習慣1: AI出力毎に1コミットを切る

Claude が出力したコードをファイルに反映したら、すぐに git add . && git commit。コミットメッセージにはプロンプトの要点を残します。

git commit -m "feat: ATR2倍SLのEAをClaudeで生成

prompt: 'EURUSD M15で、RSI70超 + EMA50>EMA200のときに買い、
SL=ATR×1.8、TP=ATR×3.0、リスク残高1%、最大同時保有3'
"

効果: 後で「なぜこの実装になったか」を追跡できる。AIへの依頼内容が記録に残り、再現可能になる。

習慣2: ブランチを「main / experiment」に分ける

main は安定動作するコードのみ、experiment はAI試行用。マージは必ずレビュー後。

git checkout -b experiment/optuna-tuning
# ... AIに依頼してコード生成 ...
git push origin experiment/optuna-tuning
# Pull Request を作成 → 自分でセルフレビュー → main にマージ

効果: 動かないコードを一旦main にマージしてしまう事故を防止。マージ前のレビューで AI の見落とし (例外処理漏れ等) に気付ける。

習慣3: 差分を必ず読む (git diff)

AIが書いたコードは「読まずにマージしたくなる」誘惑があります。これが最大の罠です。Pull Requestのdiff画面、または git diff main..experiment で必ず変更箇所を読みます。

効果: 私の経験では、これだけで以下のミスを未然に防げました:

• RISK_PERCENT が0.01 (1%) のところを0.10 (10%) に変えられていた
• 無限ループになるwhileを書かれていた
• 古いライブラリのAPIが混入していた

+α: コミット署名と認証

業務で使うリポジトリには GPG 署名を必須にすると、誰のコミットかが暗号的に保証されます。AIが書いたか自分が書いたかを後から区別する助けにもなります。

git config --global commit.gpgsign true
git commit -S -m "feat: AI生成のATRロジック (人間レビュー済み)"

「AI生成」をコミットメッセージに残すべきか

賛否ありますが、私は残す派です。理由:

• 後でバグが出た時に「AI生成 + 自分のレビュー漏れ」だと特定しやすい
• チーム開発では透明性が信頼に繋がる
• OSSプロジェクトに contribute する場合、ライセンス由来の問題を避ける助けに

まとめ

AI生成コードは速度を10倍にしますが、ミス検出は人間がやらないと品質が落ちます。Git の使い方を「1出力1コミット + ブランチ分離 + diff必読」の3点に整えるだけで、速度を保ちつつ事故を激減させられます。

参考にした情報源

• Pro Git Book – 公式
• Conventional Commits