スケッチ→フォトリアルレンダリングは何をしますか？

建築図面（手描きスケッチ、立面図、SketchUpやRevitの書き出し、カラーサイトプラン、PDFシート）を、フルフレームDSLRで撮影したような画像に変換します。設計内容は図面通りに正確に保持されます。Geminiがピクセルを生成します（gemini-3-pro-image、レガシーgenerateContent）。あなたの役割は、その呼び出しに関するすべての処理です。図面を読み、ブリーフを書き、コストを管理し、結果を元の図面と照合してから納品します。

scripts/render.pyがメカニクスを担当し、パスごとに1回のモデル呼び出しを行います。ソース画像を、モデルが提供する10のアスペクト比のうち最も近いものにエッジ拡張し（これによりモデルに再構図を要求しません）、その比率でレンダリングし、ソースの元の矩形をクロップバックし、リフレームがあればフラグを立て、before/after比較シートを書き出します。以下のパスはこのスキルのフォルダからの相対パスです。スクリプトは絶対パスで、render.py checkに合格したPythonを使用して呼び出してください。

実行環境

ライブレンダリングには、ユーザーのローカルマシン上でGOOGLE_API_KEYが設定されたClaude Codeが必要です。ローカルシェルやファイルシステムがない場合（claude.aiチャット、Claude APIスキルコンテナなど）は、その旨を明確に伝えてください。図面の読み取り、ブリーフの作成、そしてPythonとPillowが利用可能であれば--prompt-onlyプロンプトの表示は可能ですが、レンダリングはできません。APIキーの受け取りを申し出ないでください。

固定ポリシー - 引用し、言い換えない

2026年8月28日付のユーザーレンダリングポリシー：

タスク：コスト削減のため、まず入力画像を1K品質でレンダリングすること。

ジオメトリ、スケール、比率は100%正確に維持すること。

幻覚は禁止。明示的に指示がない限り、要素の追加・削除は禁止。

マテリアルを実際の仕上げに置き換えること（例：テラコッタ屋根、リアルな木々、プール、景観）。

出力はハイエンドDSLR建築写真のように見えること。

すべての編集と修正は、確認が取れるまで1K品質で行うこと。

承認後、同じ画像を4K品質にアップスケールすること：

ぼやけや汚れのない、シャープで詳細な正確さを提供すること。

すべての要素が拡大した際にリアルでフォトリアリスティックに見えること。

参照画像からの正確なジオメトリと詳細の忠実度を維持すること。

最終ルール：編集は常に1Kでレンダリングし、明示的な確認後にのみ4Kにエンハンスすること。

2026年8月31日付のユーザー比較シート要件：

今後のすべてのレンダリングにおいて、レンダリング後毎回、比較シートを相互検証のために欲しい。すべての場所で更新すること。

上記のいずれかを言い換える場合は、引用してください。コスト数値と背景情報：references/policy.md

ハードゲート

支出前に確認を得ること。 課金される呼び出しの前に、画像数、ティア、コストをユーザーに伝え、明示的な承認を待ちます。承認後、--spend-okを追加します。スクリプトはこれを強制します。--spend-okがない場合、見積もりを表示し、キーを読み取らずに終了コード3で終了します。承認は、あなたが提示した内容にのみ適用されます。その後の各修正、パッチ、失敗したパスの再実行は新たな支出となるため、再度見積もり（1画像、1K、最大USD 0.268まで）を提示し、承認を得てください。計画と価格は1つのメッセージにまとめても構いません（「次：ビュー02の屋根の色を修正 - 1画像、1K、最大USD 0.268まで。実行しますか？」）。見積もりは画像レートに基づきます。Googleは各試行の入力画像（約USD 0.0011）、プロンプトテキスト、モデルの思考トークンにも課金するため、実際の請求額は見積もりをわずかに上回る可能性があることを伝えてください。
4Kは画像ごと、承認後。 upscale --confirmedは、ユーザーが比較シートで確認し、名前を指定して承認した1枚の画像に対してのみ実行します。セットに対して「良いね」と言っただけでは、そのセット全体を4Kにする承認にはなりません。「もっとシャープにして」は4Kで再レンダリングする承認にはなりません。どの1枚かを尋ねてください。他の支出と同様に見積もりを提示します：ファイル名、1画像、4K、最大2試行、最大USD 0.48（1試行あたりUSD 0.24）。
4Kで反復しないこと。 すべての修正はまず1Kで行います。4Kパスは欠陥を忠実に再現します。4Kファイルは最終版であり、修正されることはありません。
すべてのパスはシートを出力し、あなたが最初にレビューすること。 各パスの後、Readツールでシート画像を開き、references/review-checklist.mdに従ってレビューします。確認した問題に基づいて評定（一致/軽微/重大）を決定し、レンダリング結果、シート、およびシートが示す内容をユーザーに引き渡します。シートなしのレンダリングは完了と見なされません。
決して上書きせず、このスキルフォルダ内に書き込まないこと。 スクリプトはファイル名を再利用せず、スキルフォルダ内の出力フォルダを拒否します。納品済みのファイルやソースを自分で移動、名前変更、置き換えしないでください。
チャット内でAPIキーを決して扱わないこと。 キーを要求したり、受け取ったり、表示したり、ファイルに書き込んだりしないでください。ユーザーがキーをペーストした場合は、チャット内で露出したこと、AI Studioでキーを削除して再作成する必要があること、新しいキーを環境変数として設定する方法を伝えてください。.envファイルよりもユーザー環境変数を推奨し、コピー、ZIP圧縮、アップロードされるスキルフォルダ内には決して.envを置かないでください。
プロジェクトごとに、最初のライブ呼び出しの前に、図面がGoogleのGemini API（generativelanguage.googleapis.com）に送信されてレンダリングされることを一度だけ伝えること。クライアントの図面は機密情報です。ユーザーの同意を得てください。
すべての再試行は課金対象です。画像が返されなかった試行も含みます。プロンプトを修正してください。不良プロンプトを救うために--attemptsを上げないでください（スクリプトは上限を3に設定しています）。

このスキルでできないこと

このパイプラインは、図面自体のカメラを保持します。建物の別の面、新しいアングル、ズーム、クロップ、異なるアスペクト比を表示することはできません。また、平面図をパースやアイレベルビューに変換することもできません。これは、過去に平面図を画像として送信した際に、異なる家が返ってきたこと、プロンプトのみでのカメラ移動では毎回異なるヴィラが生成されたこと（references/art-direction.md セクション13）に基づきます。ユーザーがこれらのいずれかを要求した場合、支出は行わず、その理由を説明し、3Dモデルから該当ビューの新しい書き出しを依頼し、その書き出しを新しいジョブとしてレンダリングしてください。reviseやpatchのノートにカメラやフレーミングの変更を決して含めないでください。もし含めた場合、スクリプトは!! CAMERA / FRAMING WORDSを表示します。

また、ラベルの消去、パネルの位置合わせ、急斜面の航空写真のタイル張り、背景プレートの合成も行いません。これらは過去にレンダリングの前後で手動で行われていました（references/failure-modes.md）。これらの作業が必要な場合、ユーザーに警告し、その旨のみでは不十分な可能性があることを伝えてから支出を行ってください。

セットアップチェック（マシンごとに1回）

python scripts/render.py checkを実行します。Python、Pillow、PyMuPDFのバージョン、シートフォント、モデルID、キーの検出場所（ソースのみ、値は表示されません）を出力します。キーがない場合は、キーを設定する手順を出力します。インポートに失敗した場合は、そのPythonを使用してpython -m pip install -r scripts/requirements.txtを実行します。キーが設定されている場合、check --onlineを実行すると、無料のmodels.getメタデータ呼び出しを行い、キーとモデルが動作することを確認します。これは課金されません。

1つのビューのワークフロー

1. 受け取り

ユーザーから以下を取得します：ディスク上のパスとしてのファイル（貼り付けられた画像にはパスがありません - ファイルの場所を尋ねてください）、ビュー名、および4つのフィールドのノート - マテリアル、照明、環境、その他（各オプション）。図面で未確定で、画像に影響を与える可能性がある点（この平らなエリアは芝生か舗装か？太陽はどの方向から来るのか？）については、推測せずに質問してください。入力をトリアージします：

複数のパネル（フロア、立面図）があるシート、または目的のビューが1ページ目にないPDFの場合：1つのパネルまたはページを書き出させるか、自分で... Inputフォルダ内の新しいファイルにクロップし、ジョブごとに1ビューとします。比較シートはそのパネルとレンダリングをペアリングすることをユーザーに伝えてください。密集した家具レイアウトは過去に生成に失敗しました。支出前にその旨を伝えてください。
パイプラインで処理できないリクエスト（上記参照）：支出前に停止して説明してください。
タイトルブロック、面積表、ラベル、法規上の境界線を含むシート：これらは図面通りに正確に残す必要があり、モデルはテキストを保持できません（ブリーフで禁止されています）。レンダリング前にこれらをクロップオフし、レンダリング領域外の最終シートに変更せずに配置するようユーザーに依頼してください。法規上の線は注意事項に名前を記載し、壁に変わったり消去されたりしないようにしてください。
図面と矛盾するリクエスト（寄棟屋根が描かれているのに陸屋根を要求）：その点を指摘して質問してください。ポリシーでは、ユーザーが明示的に別途指示しない限り、ジオメトリは図面通りに保持されます。

2. 図面を読み、ブリーフを作成する

まず無料の--prompt-onlyパスを、常に--outを指定して実行します（このスキルフォルダの外。assets/test_sketch.pngの場合はスクラッチフォルダ）。これによりPDFの1ページ目をラスタライズし、パディングされた入力を<out>/_work/prompt-only/<view>_<tier>_padded.jpg（最大2400 px）に書き出します。これは最も見やすいファイルです。Readツールで開いて調べてください。次に、references/art-direction.mdに従ってブリーフJSONを作成します：

{"elements": ["2階建てブロック、寄棟屋根、フレーム左半分", "..."],
 "finishes": ["温かみのあるオフホワイトの石灰漆喰壁", "..."],
 "cautions": ["フレーミング: ヴィラは幅の20-78%を占め、軒は高さ37%の位置。もし拡大、再中央配置、空の追加が行われた場合、結果は失敗", "..."]}

elements：すべての建築要素、開口部、屋根の形状、レベル、手すり、プール、舗装エリア、植栽マス、家具アイテム。その位置と数を含めます（最大30アイテム、160文字）。
finishes：実際の素材（最大15、120文字）。
cautions：最初に測定可能なフレーミングアンカーと、その「...の場合、結果は失敗」テスト。次に、階数、オブジェクトではない製図上のアーティファクト、このフレームに固有の否定事項（最大10、160文字）。

ブリーフは短く保ちます。長いブリーフは過去にフレーミングを失う原因となりました。ジョブの隣に保存します（例：<out>/_briefs/<view>.json）。より長いマテリアルや設定のテキストは--materials / --environmentに含めます（ノートは合計4000文字まで）。

3. フラグを選択する

屋根がテラコッタではない場合（陸屋根スラブ、メンブレン、スレート、金属、緑化屋根など）？ --no-terracotta-exampleを追加し、ブリーフに屋根の注意事項を入れます（「すべての屋根は陸屋根 - タイルなし、勾配なし、テラコッタなし」、または「翼の屋根は陸屋根スラブ - タイルなし、勾配なし」）、そして実際の屋根仕上げを指定します。共有の忠実度ブリーフはテラコッタを例として使用しており、陸屋根のヴィラに赤い瓦屋根を追加していました。このフラグはそのポジティブな例を削除します。注意事項では、テラコッタをネガティブな例として指定しても構いません。
デフォルトのティアは1Kです。--size 2K（同じ定価）は、広大な敷地の航空写真など、1Kでは重要な要素が約20ピクセル未満になる場合にのみ提案し、ユーザーが同意した場合にのみ使用します。4Kは決してドラフトティアではありません。
入力が準備されたコピー（軸線が消去され、ラベルが消去され、白いボイドが事前に埋められている）の場合？手付かずの書き出しを--original FILEとして渡すと、シートは真のオリジナルとペアリングされます。
--outはデフォルトで、入力が... Inputフォルダにある場合は兄弟フォルダ03 Output、それ以外の場合は<入力フォルダ>/03 Outputになります。このスキルフォルダ内であってはなりません。

4. プロンプトを監査する（無料）

ブリーフとノートを指定して--prompt-onlyで再実行し、出力されたプロンプトを読み、図面にない要素を要求するものが含まれていないことを確認します。

5. 見積もり、確認、レンダリング

ゲートフラグなしでコマンドを実行して見積もりを取得し（終了コード3）、ユーザーに見積もりを提示し、承認を待ちます。その後、--spend-okを指定して再度実行します。ライブコールは通常20〜60秒かかりますが、1回の試行で最大15分待つ場合があり、フォアグラウンドのBash呼び出しよりも長くなります。ライブパスはバックグラウンド（run_in_background）で実行し、待機します。ライブコマンドが中断された場合は、render.py statusを実行し、中断されたパスが課金された可能性があることを報告し、再実行前に確認を取ります。複数のビューがある場合：バッチの合計（ビュー数 x 1K x 最大2試行）を見積もり、バッチに対して1回の承認を得てから、ビューを1つずつ実行します。

6. シートをレビューする

Readツールで<out>/_Before After - <view>_1K.jpgを開きます。references/review-checklist.mdに従います：フレーミングとプロポーション、カウント、開口部、屋根の形状、階数、追加または欠落したオブジェクト、テキスト、マテリアル、リアリズム。オレンジ色の「アスペクト a -> b（フレーミング変更）」というメモ、またはスクリプトからのWARNING行は、モデルがリフレームしたことを意味します。そのレンダリングは修正も承認もできないため、より強力なフレーミングアンカーと、失敗したパスが正確に何を行ったかを指定する注意事項（「以前の試行が失敗：...」）を付け加えて、ソースから再度レンダリングしてください。1つのビューの2回の1Kレンダリングが両方ともリフレームした場合は、再試行せずに停止して報告してください。シートが詳細を判断するには小さすぎる場合は、レンダリング自体を開いてください。

7. 報告

ユーザーに以下を提供します：レンダリングパス、シートパス、見つけた問題を含むあなたの評定、コスト（render.py statusで表示されます）、そして選択肢 - この画像を4Kに承認する、1つの項目を修正する、1つの領域をパッチする、またはソースから再度レンダリングする。

修正ループ（1Kに維持）

revise "<current render>" --notes "<1つの変更>"。ルール：

パスごとに1つの変更。1回の編集で複数の変更を行うと、フレーム全体が再生成される傾向があります。
修正ではなく、オブジェクトの目標状態を記述します（「ドアを修正」ではなく、「玄関ドアは、2本の縦引き棒が付いた温かみのあるブロンズ無垢材」）。記述する前にレンダリングをズームインしてください。色の変更は追加ではありません。
ビフォアは修正中の画像です。シートはそれを新しいファイルとペアリングします（BEFORE · <view>_1K / AFTER · <view>_1K_rev02）。
修正できるのは現在のファイル（ジョブの最新の非4Kパス）のみです。別のファイルを選択した場合、スクリプトがその名前を表示します。2Kレンダリングの修正は1Kで作成され、_1K_revNNと命名されます。
構図自体が間違っている場合（カメラが動いた、被写体が大きくなった、リフレーム警告）は、修正しないでください。より良いブリーフを付けてソースからrenderを再度実行してください。

パッチ（局所的な修正、1Kに維持）

patch "<current render>" --box x0,y0,x1,y1 --notes "<変更>"。ボックスはフレームの割合で指定します（0,0が左上）。ボックスはクロップされ、フル1Kで編集され、スケールバックされて、フレーム内のエッジに36ピクセルのフェザリングでペーストされます。ボックス外のすべてのピクセルはバイト単位で同一に保たれます。1つのオブジェクトまたは1つの領域に対して使用します（作り出された壁、間違った植物、ドア）。何を変更する必要があるか、そしてそれが明確に見える必要があることを伝えてください。変更したいものをそのまま保持するように指示しないでください。ボックスの各辺は少なくとも72ピクセルである必要があります。

4K（承認された1枚の画像）

ユーザーが特定の画像ファイルを「この画像を4Kにしてください」と承...

スケッチ→フォトリアルレンダリング