HiAPI
Ja
ブログ

使用ガイド

Grok 4.7 プロンプト大全：5つのシナリオをそのままコピー

実際に実行した5つのプロンプト：並行処理のトラブルシューティング、JSON 形式コードレビュー、設計比較、概念解説、pandas 分析。実際の出力と1回あたりのコスト付き

Oct 29, 2026
Grok 4.7 プロンプト大全：5つのシナリオをそのままコピー

TL;DR：5つのシナリオをすべて grok-4.7 で HiAPI の本番環境で実実行し、出力原文をそのまま掲載。1回あたりのコストは $0.007–0.021、5本実行しても約 $0.06。各プロンプトの下にあるリンクをクリックすると同じプロンプトがモデルページに自動入力され、送信すれば再現できます。Grok 4.7 は HiAPI に公開済み。モデルページを開くとすぐに試せます。新規ユーザー登録で200クレジットを進呈。

シナリオ 1：並行処理のデッドロックを調査

根本原因はレスポンスオブジェクトが解放されておらず、接続がずっと connector プールのスロットを占有していることです。

session.get() が返す ClientResponse は、release() / close()（または非同期コンテキストマネージャの終了）のときに初めて接続を TCPConnector に返却します。現在の書き方には async with も明示的な release() もありません。body を読み終えても接続は返却されず、レスポンスと connection の間には循環参照があり、循環 GC の __del__ を待つしかありません。

デフォルトでは各 ClientSession の接続上限は100です。20個の worker がそれぞれ1つの session を保持し直列にリクエストを送り、各 worker は約250個の URL を処理します。接続が返却されない場合：

  1. 占有された接続はサーバー側のアイドルタイムアウトや接続数制限により RST され、aiohttp がプロトコル層で ConnectionResetError を出します（必ずしもあなたの await からスローされるわけではないので、except で捕捉できず、クリーンアップもできません）。
  2. スロットは依然として占有されたままです。100に達すると、次の session.get() は connector.acquire() でブロックし、しかもこの待機は多くの場合 timeout の制約を受けません。
  3. 全 worker が acquire で詰まり、queue.get() も task_done() も実行しなくなります。イベントループ上で新たな割り当てがなく、循環 GC も走らなくなり、__del__ が接続を回収できずデッドロックに陥ります。queue.join() も永遠に待ち続けます。

except Exception: pass はユーザーコルーチン内の例外を飲み込むだけで、接続は解放できないため、「エラー」と「デッドロック」が同時に発生します。

最小限の変更：

async def fetch(url, session):
    async with session.get(url) as r:
        return await r.json()

async with は正常リターンと例外の両方の経路で __aexit__ → release() を通ります：

  • 接続は即座にプールへ返却され、スロットが100まで溜まることはなく、session.get() が acquire で永久にブロックすることもなくなり、worker はキューを消費し続けられます。これがデッドロックを解決します。
  • 接続がサーバー側の RST を待つ形で長期的に占有されなくなり、プロトコル層の ConnectionResetError も消えます。body 読み取り中に実際に切断が起こっても、コンテキストマネージャがこの接続を返却またはクローズするため、1回の失敗でプールが破綻することはありません。これがエラーを解決し、エラー発生後もキューが進められることを保証します。

完全なプロンプト：

以下の Python コードは、並行数がやや多くなるとランダムに ConnectionResetError が発生し、その後 worker 全体がデッドロックしてキューを消費しなくなります。根本原因を特定し、最小限の変更による修正を示してください。さらに、その修正が「エラー」と「デッドロック」の両方の問題を同時に解決できる理由を説明してください。

```python
import asyncio, aiohttp

async def fetch(url, session):
    r = await session.get(url)
    return await r.json()

async def worker(queue):
    session = aiohttp.ClientSession()
    while True:
        url = await queue.get()
        try:
            data = await fetch(url, session)
            print(data)
        except Exception:
            pass
        queue.task_done()

async def main():
    queue = asyncio.Queue()
    for i in range(5000):
        queue.put_nowait(f"https://api.example.com/item/{i}")
    workers = [asyncio.create_task(worker(queue)) for _ in range(20)]
    await queue.join()

asyncio.run(main())
```

このプロンプトで生成 →

grok-4.7、デフォルトの high 推論ティア、max_tokens 上限 6000、実実行 107.7s、入力 3,572 / 出力 7,301 tokens、約 $0.021。

症状、コード、「2つの問題を必ず同時に説明すること」という制約を一度にすべて与えることで、モデルは表面的な try-catch の修正で止まらず、接続プールという根本原因まで特定できます。

シナリオ 2：コードレビューで JSON を出力

{"issues":[{"severity":"high","line":8,"problem":"残高チェックと引き落としが分離しており、TOCTOU 競合状態が存在する：並行リクエストが同時に残高判定を通過して二重引き落としが起こり、残高超過や二重支払いにつながる","fix":"単一の条件付き更新（balance>=amount の場合のみ $inc するなど）に変更するか、トランザクション内で行ロック／楽観ロックを使いチェックと引き落としを原子的に完了させる"},{"severity":"high","line":9,"problem":"引き落としと入金は2回の独立した書き込み操作でトランザクションがない。1回目が成功し2回目が失敗すると、資金は from から消えたままロールバックできない","fix":"2つの更新を同一データベーストランザクションに入れ、どちらかが失敗したら全体をロールバックする。また to アカウントの存在を確認してからコミットする"}

,"summary":"この振込 API は原子的トランザクション、認可、入力検証を欠いており、並行時には二重支払いや資金消失が発生し、例外経路ではリクエストがハングする。"}

（抜粋：元の出力は1行の JSON で、先頭2件の high 問題と summary を保持し、残りは省略）

完全なプロンプト：

以下の Node.js ルートコードをレビューし、本番事故につながる問題をすべて洗い出してください（セキュリティ、並行性、リソースリークを含む）。重大度順に並べてください。厳密に JSON で出力し、形式は：{"issues": [{"severity": "high|medium|low", "line": 行番号, "problem": "問題", "fix": "修正方法"}], "summary": "一言まとめ"}。

```js
const express = require('express');
const db = require('./db');
const router = express.Router();

router.post('/transfer', async (req, res) => {
  const { from, to, amount } = req.body;
  const fromAccount = await db.findOne({ id: from });
  if (fromAccount.balance >= amount) {
    await db.update({ id: from }, { $inc: { balance: -amount } });
    await db.update({ id: to }, { $inc: { balance: amount } });
    res.json({ ok: true });
  } else {
    res.status(400).json({ ok: false });
  }
});

module.exports = router;
```

このプロンプトで生成 →

grok-4.7、デフォルトの high 推論ティア、max_tokens 上限 4000、実実行 40.1s、入力 3,576 / 出力 2,734 tokens、約 $0.010。

プロンプトに望む JSON の骨格（フィールド名、並び順のルール）を直接書けば、grok-4.7 は厳密にその形式で出力し、そのままパイプラインに投入できます。

シナリオ 3：技術設計の比較

「アクティビティ heartbeat + Redis TTL + 必要に応じた短いポーリング」を推奨します。WebSocket/SSE で全量のオンライン状態をプッシュするのは避けてください。5分でグレーになる表示に秒単位のプッシュは不要で、DAU 10万でもポーリングで十分に耐えられ、Next.js との相性も良いです。

方式の比較

ポーリング SSE WebSocket
方向 クライアントが取得 サーバーから一方向プッシュ 双方向
「5分間アクティビティなしでグレー」との相性 高。30–60s の更新で緑ドットには十分 中。プッシュは速いが、タイムアウトでグレーにする計算は自前で必要 低〜中。接続がオンラインであること ≠ ユーザーがアクティブであること
Next.js との適合性 最良。通常の Route Handler 不良。長接続は Serverless/マルチインスタンスと相性が悪い 最悪。独立した WS プロセス、スティッキーセッション、またはサードパーティが必要
接続コスト 長接続なし オンラインユーザーごとに1本 オンラインユーザーごとに1本、さらに heartbeat で維持が必要
拡張性 ステートレスで水平拡張が簡単 切断、再接続、マルチインスタンスへのファンアウトを管理する必要 同左でさらに重い
障害モード あるリクエストが失敗したら次回取得すればよい 切断後は状態更新が止まり、補完取得が必要 同左で、ゲートウェイが複雑
DAU 10万で価値があるか ある。デフォルト方案として 既存のプッシュチャネルがある場合のみ価値がある 既存のチャット/コラボゲートウェイがある場合のみ価値がある

ピークの概算：DAU 10万、同時オンラインを5%–15%と見積もると約0.5万〜1.5万。heartbeat を45秒に1回で約100–300 writes/秒、各ユーザーが30秒ごとに表示中のユーザー状態をまとめて取得するとして、読み取りも Redis の快適な範囲です。ボトルネックは「緑ドット」にはなりません。

推奨と理由

Redis をオンライン状態の真実の源とし、PostgreSQL はコールドな last_seen のみ、クライアントは現在画面に表示されているユーザーのみをポーリングする構成にします。

  1. プロダクトの意味は「5分間アクティビティなし」であり、「TCP がまだ接続している」ことではありません。ページを開いたまま動かなければグレーになるべきなので、WS を使っても別途アクティビティ heartbeat が必要です。接続自体では要件を解決できません。
  2. 緑ドットは数十秒の誤差を許容できます。ポーリング間隔30–60秒は、5分のウィンドウに対して十分です。
  3. Next.js（特に Vercel / Serverless）は長接続の維持に向きません。WS/SSE は独立したリアルタイムサービス、スティッキールーティング、切断補償に引きずり込むわりに、得られる効果は小さいです。
  4. 誰が誰の状態を見るべきかは通常ローカル（友達、会話リスト、現在のページのアバター）であり、サイト全体へのブロードキャストではありません。id で Redis をバッチ取得する方が、購読関係を維持するより一桁簡単です。
  5. Redis キーの期限切れは「タイムアウトでオフライン」を自然に表現でき、keyspace notification や全表スキャンに頼る必要はありません。
ユーザーレベルの存在＝オンライン（推奨メイン方式）：

```text
presence:u:{userId}   STRING  値 = サーバー側 unix ミリ秒
                      TTL = 300 秒
                      heartbeat 時に SET key value EX 300
                      オンライン = キーが存在する
```

クライアント時刻は使わないでください。TTL を heartbeat 間隔の2–3倍より大きくする必要はなく、ここでは heartbeat 45–60秒、TTL 300秒で、2〜3回 heartbeat を落としてもオンライン扱いとなり、「5分間アクティビティなし」に合致します。

（抜粋：推奨結論と最初の5つの理由、Redis キー設計のうちユーザーレベルのメイン方式）

完全なプロンプト：

DAU 10万の Web アプリに「リアルタイムオンライン状態」機能（ユーザーアバターの横に緑ドットを表示し、5分間アクティビティがなければグレーにする）を追加したい。技術スタックは Next.js + PostgreSQL + Redis。まず方式の比較（WebSocket / SSE / ポーリング）を示し、どれを推奨するかとその理由を説明し、その後に実装手順と Redis キー設計を列挙してください。完全なコードは書かず、重要な断片のみ貼ってよい。

このプロンプトで生成 →

grok-4.7、デフォルトの high 推論ティア、max_tokens 上限 6000、実実行 69.8s、入力 3,429 / 出力 4,247 tokens、約 $0.014。

技術スタックとビジネス規模を先に限定し、その上で「まず比較してから推奨」を求めることで、出力は中立な解説ではなく、そのままレビューに出せる設計案になります。

シナリオ 4：概念の解説

まずシナリオを明確にしましょう。注文処理を行っているとします：注文をデータベースに書き込み、同時にメッセージキューに1件メッセージを投げて、在庫、ポイント、通知などの下流に処理させる必要があります。この2つの操作は同じ「トランザクション」にはなく、途中のどのステップが失敗しても「片方は成功、片方は起きていない」という亀裂がシステムに生じます。

先にデータベースへ書き、その後にメッセージを送ると、なぜメッセージが失われるのか

データベースのコミットが成功し、注文はすでに保存されています。その直後にプロセスがメッセージを送ろうとしますが、このとき以下の可能性があります：

  • ネットワークが一瞬不安定になり、送れない；
  • メッセージキューが一時的に利用できない；
  • より一般的なのは、プロセスがデータベースコミット後、メッセージ送信前にそのままクラッシュする（マシン再起動、OOM、デプロイのローリング）。

注文はデータベースにあり、メッセージは永遠に送られません。下流はこの注文があったことをまったく知らず、在庫は減らず、通知も送られません。後からリトライしても無駄です——クラッシュしたプロセスはもう存在しないので、別途信頼できる補償を実装していない限り、このメッセージは失われます。モノリシックしか書いたことのない人にとっては、これは次のようなものです：まず帳簿に「入金済み」と記録し、それから郵便局へ通知書を出しに行き、手紙は途中で失われたのに帳簿はすでに書き換わっていて、両方が食い違う。

（抜粋：「先に DB に書いてからメッセージを送る」のメッセージ喪失メカニズムと核心的な比喩）

完全なプロンプト：

3年の経験があるが分散システムにはまったく触れたことのないバックエンドエンジニアにわかる言葉で、なぜ「先にデータベースへ書き、その後メッセージキューを送る」とメッセージが失われる可能性があるのか、また「先にメッセージキューを送り、その後データベースへ書く」のもなぜダメなのかを説明してください。業界でよく使われる2つの正しいやり方（ローカルメッセージテーブル / トランザクションメッセージ）がそれぞれどんなシナリオに適しているかも示してください。

このプロンプトで生成 →

grok-4.7、デフォルトの high 推論ティア、max_tokens 上限 4000、実実行 41.3s、入力 3,410 / 出力 2,478 tokens、約 $0.009。

「もっとわかりやすく」の代わりに「具体的な人物像に向けて話す」と指定すると、モデルが自分で適切な粒度を選びます。帳簿と郵便局の比喩はこうして生まれました。

シナリオ 5：データ分析スクリプト

```python
import pandas as pd
import numpy as np

# サンプルデータ（実際の df に置き換え可能）
np.random.seed(42)
n = 500
df = pd.DataFrame({
    "order_id": range(1, n + 1),
    "user_id": np.random.randint(1, 80, n),
    "amount": np.round(np.random.uniform(20, 500, n), 2),
    "created_at": pd.date_range("2023-01-01", periods=n, freq="D").astype(str),  # 文字列日付をシミュレート
    "status": np.random.choice(["paid", "paid", "paid", "cancelled"], n),
})

# ---------- 0. 日付処理：文字列を datetime に変換 ----------
df["created_at"] = pd.to_datetime(df["created_at"], errors="coerce")
df = df.dropna(subset=["created_at", "amount", "user_id"])

# 任意：有効注文のみを集計（実際の業務に合わせて status の値を調整）
df_valid = df[df["status"] == "paid"].copy()

# ---------- 1. 月ごとの GMV と注文数 ----------
df_valid["month"] = df_valid["created_at"].dt.to_period("M")
monthly = (
    df_valid.groupby("month", as_index=False)
    .agg(GMV=("amount", "sum"), order_count=("order_id", "count"))
    .sort_values("month")
)
monthly["month"] = monthly["month"].astype(str)
print("=== 月ごとの GMV と注文数 ===")
print(monthly)
```

（抜粋：コード前半（日付処理 + 月ごとの GMV）。後半のユーザーランキングと初回注文の推移は省略）

完全なプロンプト：

pandas で EC の注文データを分析しています。データフレーム df には列 order_id, user_id, amount, created_at, status があります。完全に実行可能な Python コードを書いて、以下を計算してください：1) 月ごとの GMV と注文数；2) ユーザーごとの累計消費ランキング（上位20のみ）；3) 新規ユーザーの初回注文平均金額の月別推移。created_at が文字列である場合の処理を要求し、重要なステップにコメントを付けてください。

このプロンプトで生成 →

grok-4.7、デフォルトの high 推論ティア、max_tokens 上限 5000、実実行 18.5s、入力 3,440 / 出力 1,427 tokens、約 $0.007。

列名、計算する指標、エッジケース（created_at が文字列）を項目ごとに列挙すれば、生成コードはそのまま実行でき、手戻りがありません。

プロンプトの書き方

  1. 実際のコード、実際の列名を貼る。「あるコードがある」と説明せず、直接貼り付ける。
  2. 出力形式をプロンプトに書く：JSON が欲しければ JSON の骨格を示し、コードが欲しければ「完全に実行可能」と書く。
  3. 制約は具体的であるほどよい：並び順のルール、上位20のみ、完全なコードは不要で重要な断片のみ、など。

よくある質問

これらのプロンプトはそのまま使えますか？ 使えます。5本すべて HiAPI 上で実際に実行したオリジナルのプロンプトで、出力は実行して得られた実際の結果です。各項目の下にある「このプロンプトで生成」をクリックするとモデルページに自動入力されるので、自分のコードやデータに置き換えればそのまま使えます。

grok-4.7 のコーディング能力はどうですか？ xAI はコーディングと知識作業向けと位置づけており、公式に自己申告している Terminal-Bench 4.0 は grok-4.6 の 20.3% から 38.0% に向上しています（公式の数値）。上記シナリオ 1 の根本原因特定やシナリオ 2 のレビューリストは私たちが実際に実行したものなので、ご自身で判断してください。

1回の呼び出しはだいたいいくらですか？ HiAPI プラットフォームの価格（入力 $0.84 / 出力 $2.52 每 1M tokens）で計算すると、この5本の合計は約 $0.06。最も安いシナリオ 5 は約 $0.007、最も高いシナリオ 1 は約 $0.021 です。

500K コンテキストはどう使いますか？ 中規模リポジトリ全体のファイルや数百ページのログを1回のリクエストに貼り付けて、レビュー、トラブルシューティング、リファクタリングを行えます。自分で分割する必要はありません。日常的な短いプロンプトでは使い切らなくても余分に課金されることはなく、実際の token 数で課金されます。

続きを読む

タグプロンプトcodingAPIプロンプトzh-33246dda

関連記事

すべての記事を見る →

永続的なAIアーティファクトで開発を始める

APIキーを取得して、タスクベースの1つのAPIで画像・動画・音声モデルを呼び出せます。

APIドキュメントを読む