female-portrait-director：ポートレートのプロンプトを再利用できる Skill にする

ポートレートを生成する人なら、誰もが同じことをやっています。前回せっかく使えるプロンプトを組み上げたのに、今回はシーンが変わってまた一から書き直す。カフェに変えれば光の指定を足し、古風に変えれば衣装の語を入れ替え、うっかり「清純」と「香港レトロ」のキーワードを混ぜると、出てくる顔がスタイル間で混ざり始めます。さらに厄介なのは制御できない部分です。9:16 と書いたのに正方形になり、ファッション写真だけが欲しいのにモデルが勝手にフィルターを足す。

female-portrait-director が解こうとしているのは、まさにこの「プロンプトが再利用できない」問題です。これはオープンソースの AI ポートレートプロンプトのディレクター Skill で、少数の構造化パラメータを渡すと、明示的に指定した方向をロックし、スタイルルートを 1 つだけオンデマンドで読み込み、パラメータを「撮られた一枚」のような連続したプロンプトに拡張し、ネガティブ制約を添えます。その価値は、また万能プロンプトを 1 セット配ることではありません。プロンプトを毎回書き直す使い捨てテキストから、境界を持つ再利用可能で保守しやすいインターフェースに変える点にあります。分解する価値があるのは背後にある 4 つの設計で、どんなプロンプトにも応用できる部分です。

まず手書きのプロンプトと何が違うのか

長い手書きのポートレートプロンプトの問題は、出来が悪いことではありません。使い捨てだということです。シーンが変われば語を半分手で直し、スタイルが変われば共存できないキーワードを覚えておく必要があり、2 週間後に見返すと、なぜそう書いたのか自分でもわかりません。

3 つのやり方を並べると、違いははっきりします。

テンプレートは素のプロンプトよりずっと良く、これについては再利用できる 12 種類のプロンプト設計パターンがあります。ただテンプレートの天井は「コピーして手直し」で、スタイル分離は強制できず、安全境界も拾えません。Skill はもう一歩先で、入力をフィールドに収束させ、ルールをファイルに沈め、AI にそのルールで動かせます。

30 秒で知る female-portrait-director

このプロジェクトは李岳 氏が開発し、MIT ライセンスで、2026 年 6 月時点のバージョンは V1.4.1 です。Codex Skill の形で配布され、汎用の agent skill 標準（name と description を持つ SKILL.md）に従います。導入後はチャットで $female-portrait-director と入力すれば呼び出せます。

動き方は最小のフローで言い表せます。テンプレートに沿っていくつかのフィールドを埋めると、4 つの構造化された結果が返ります。

🔥 需要のない製品に3ヶ月も無駄にするな！少額の予算で Adsterra を使い、SaaS の訴求を今すぐ検証 ➡️

今すぐ検証 →広告

入力（最小テンプレート）:
スタイル: 清純なライフスタイルポートレート
シーン: カフェの窓際の席
衣装: 白いニットカーディガン + 明るい色のインナー
雰囲気: 清潔で柔らかい
アスペクト比: 9:16

出力（4 セクション）:
1. ロックされたパラメータ: 入力をフィールドごとに反映
2. モジュール分析: 顔 / 体型 / 衣装 / シーン / カメラ / ライティング / フィルターの扱い方
3. 最終プロンプト: そのままコピーできる 1 つのまとまり
4. ネガティブ制約: 避けるべきもの

出力に要約式の羅列がない点に注目してください。渡したいくつかのフィールドを具体的な画面に拡張する。これがテンプレートとの根本的な違いです。プロジェクト自身の言葉では、例は完成度を示すもので固定テンプレートではなく、毎回イベント、動作、環境の細部を選び直すべきだとしています。

導入と最初の呼び出し

npx でワンライナー導入

最も速いのは npx でグローバルの Codex skills に入れる方法です。

npx skills@latest add liyue-aigc/female-portrait-director -g -a codex -y

後で更新するには次を使います。

npx skills@latest update female-portrait-director -g -y

Codex の skills ディレクトリに手動で clone することもできます。Windows PowerShell の場合:

git clone https://github.com/liyue-aigc/female-portrait-director.git "$env:USERPROFILE\.codex\skills\female-portrait-director"

macOS または Linux の場合:

git clone https://github.com/liyue-aigc/female-portrait-director.git "${CODEX_HOME:-$HOME/.codex}/skills/female-portrait-director"

導入後は Codex を再起動するか新しい会話を開き、$female-portrait-director と入力して起動します。知っておく価値のある仕組みが 1 つあります。Codex はプログレッシブディスクロージャーを使い、普段は各 skill の名前、説明、パスだけをコンテキストに入れ、初期リストはコンテキストウィンドウの約 2%、ウィンドウが不明なときは 8000 文字を上限とします。その skill を使うと判断したときに初めて SKILL.md の全文を読みます。つまり skill を大量に入れてもコンテキストを占有し続けないわけで、この後の内部設計を理解する上で重要です。具体的なバージョンとコマンドはリポジトリの README を基準にしてください。

分解 1：パラメータロックで、指定が書き換えられないようにする

ポートレートプロンプトが最もよく崩れる原因は、明示的に指定したものをモデルがこっそり変えてしまうことです。9:16 と書いたのに正方形になり、ファッション写真だけが欲しいのに勝手にフィルターを足す。

female-portrait-director の第 1 層の設計が、このパラメータロックです。22 個のパラメータを定義し、スタイル、シーン、衣装、配色から、カメラ、ライティング、アスペクト比、用途まで、各フィールドにデフォルト値があります。ルールは厳格で、ユーザーが明示的に書いたフィールドをロックし、欠けたものだけを補い、方向は置き換えません。プロジェクトの FAQ によれば、ロックするのは選んだ方向であって画面の細部ではないので、創作を制限せず、システムは自然に起きる瞬間、動作の連鎖、視線の落とし先を補います。

アスペクト比のような強い制御には、もう一段の手当てがあります。プロジェクトはアスペクト比とピクセルサイズを、指定どおりの値で最終プロンプトの 1 文目に置くよう求めます。理由は上の古い問題です。中間や末尾に置くとモデルは無視しがちで、1 文目に強い制約として置くと出力比率が安定します。

自分の場面に置き換えると、この層はプロンプトにデフォルト付きの入力 schema を定義するのと同じです。どのフィールドをユーザーに委ねるか、どれを自動で補えるか。先に整理して初めて、プロンプトは再利用の話ができます。

分解 2：オンデマンドルーティングで、一度に 1 つのスタイルだけ読む

このツールは 14 種類のスタイルに対応し、清純なライフスタイル、都会的ファッション、EC モデル写真から、古風ファンタジー、香港レトロ、新中華風まであります。自然な疑問は、なぜ 14 種類すべてを 1 つの長大なプロンプトに詰め込んでモデルに選ばせないのか、です。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

詰め込むと混ざるからです。古風のキーワードと香港レトロのキーワードが同時に存在すると、モデルは両者の特徴を 1 つの顔に混ぜやすくなります。プロジェクトのやり方は、軽量なスタイルレジストリ（style-registry）を唯一の振り分け入口にし、各リクエストでスタイルルートのファイルを 1 つだけ一致させて読み込み、残りの 13 個はコンテキストに入れません。FAQ ははっきり書いています。オンデマンド読み込みは無関係なルールがコンテキストに入るのを減らし、スタイルの混ざりやテンプレ化を抑え、処理効率も上げます。

この考え方は、先に触れた Codex のプログレッシブディスクロージャーと同じ設計思想で、層が違うだけです。Codex はフレームワーク層で skill の説明だけを先に読み込み、一致すると全文を読む。female-portrait-director は skill の内部でもう一度それをやり、まずレジストリを見て、一致したそのスタイルだけを読む。どちらも同じ問いに答えています。コンテキストは希少資源だから、一度に全部入れない。

応用点も明確です。プロンプトが多くのスタイル、シーン、タスク種別をカバーするなら、巨大な 1 本にせず、レジストリとオンデマンド読み込みの構造で、毎回は関係する一部だけを読み込ませます。

分解 3：モジュール化したディレクター式拡張で、パラメータを画面に変える

標準出力が埋めたフィールドを並べ替えるだけなら、テンプレートと変わりません。female-portrait-director は、標準出力を要約にしてはいけないと強調します。要約では生成を安定して制御できないからです。

画面を 7 つの視覚モジュールに分けます。顔、体型、衣装、シーン、カメラとポーズ、ライティング、フィルターです。標準詳細版の最終プロンプトは必ず 5 段落で、人物と雰囲気、時間の切り取りと動作、体型と衣装、シーンとカメラ、ライティングとフィルターの順に扱います。ディレクター式拡張とは、時間の切り取りに小さな出来事、動作の連鎖、視線の落とし先、2〜3 個の選択的な環境の細部を加えて、これらのフィールドを 1 つの連続した瞬間に融合することで、フィールドをリストに積み上げることではありません。

具体的な違いを挙げます。要約式は「白いカーディガン、カフェ、柔らかい光」と書きます。ディレクター式は撮られた一枚として書きます。窓際の席で、彼女はカップを置いたばかり、視線は窓の外に向き、午後の光が左から斜めに差し込む。後者は生成を安定して制御でき、前者は運任せです。

この層が教えてくれるのは、再利用はテンプレートの穴埋めではないということです。構造化は安定のためですが、拡張と推論の余地を残さないと、再利用して出てくるのは似たり寄ったりの画ばかりになります。

分解 4：安全境界と出力フォーマット、再利用できるほど制御も要る

ポートレートプロンプト一式を誰でも呼べる Skill にすると、コンプライアンスのリスクは拡大します。だから境界は毎回記憶に頼るのではなく、ルールに書き込む必要があります。

female-portrait-director の安全境界は明確です。デフォルトでは架空の、明確に成人の女性を生成します。同一性の保持は本人または許可を得た成人の参照画像でのみ許可されます。未成年の性的表現、露骨な裸体、非同意の画像、なりすましは禁止です。曲線を強調するスタイルでも、プライベートな部位の露出や年齢が曖昧な構図は避けるよう求めます。これらはプロジェクトが備える責任ある利用の制約で、実際の生成では利用するプラットフォームの規約と現地の法律にも従う必要があります。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

出力フォーマットも制御の一形態です。最終プロンプトとネガティブ制約を、それぞれ text タグ付きの独立したコードブロックに置き、見出しはブロックの外に残してコピーしやすくし、分析をコピー用の内容に混ぜないよう求めます。細部は小さく見えますが、再利用には重要です。呼び出す側は常に同じ予測可能な構造を受け取れます。

やってみる：プロンプトを Skill に収束させる 5 ステップ

この考え方はポートレートに限りません。何度も書き直すプロンプトなら、次の 5 ステップで Skill に収束させられます。

1. パラメータ schema を抽出する。毎回変える内容をフィールドにし、各フィールドにデフォルト値を与える。どれをユーザーが決め、どれを補えるかを整理します。
2. レジストリでオンデマンド読み込みを作る。スタイルやタスク種別が多いなら軽量な入口テーブルを作り、毎回は一致した 1 つのルールファイルだけを読み込みます。
3. ディレクター式の拡張ルールを書く。フィールドを並べ直すのではなく、連続した結果に拡張する方法を定めます。
4. 安全境界と出力契約を決める。禁止事項と出力構造を固定し、どの呼び出しでも予測可能なフォーマットが返るようにします。
5. SKILL.md にまとめる。name と description を明確に書き、トリガーの場面と境界を説明して、エージェントが暗黙的に一致できるようにします。

最小の SKILL.md 骨格

自分の領域に合わせて中身を差し替えてください。これは自作の例で、プロジェクトの原文ではありません。

---
name: my-prompt-skill
description: ユーザーが X 系のプロンプトを必要とするときに起動。少数のフィールドを入力し、構造化された結果とネガティブ制約を出力する。
---

# フロー
1. フィールドを読み、ユーザーが明示的に書いた項目をロックし、欠けた項目はデフォルト値で補う。
2. レジストリから一致するスタイル/タスクルートを 1 つ選び、それだけを読み込む。
3. ディレクター式ルールで連続した結果に拡張する。フィールドを羅列しない。
4. 最終結果とネガティブ制約を、それぞれ独立したコードブロックで出力する。

実装でよくある落とし穴と対処は次のとおりです。

誰に向くか、向かないか

すべてのニーズが Skill 化に値するわけではありません。判断の目安です。

female-portrait-director から本当に学ぶべきは 14 種類のスタイルではなく、プロンプトを工学的な対象として扱う姿勢です。入力には schema があり、ルールはオンデマンドで読み込み、拡張には方法があり、境界はファイルに書かれている。Skill の仕組み自体を知りたいなら、まず Claude Code の Skill 機能を読み、繰り返しの制作をパイプライン化したもう 1 つの事例は guizang-social-card-skill を、ポートレートプロンプト自体の書き方を補うなら Stable Diffusion プロンプトテンプレートガイド を参考にしてください。

まとめ

female-portrait-director は、ポートレートプロンプトに対して多くの人がやっていないことをやりました。毎回書き直すテキストから、入力 schema、オンデマンドルーティング、ディレクター式拡張、明確な境界を持つインターフェースに変えたのです。そのポートレート機能を使う必要はなくても、4 つの設計は、何度も調整するどんなプロンプトにもそのまま移せます。次の一歩はシンプルです。毎週 2〜3 回書き直しているプロンプトを 1 つ選び、あの 5 ステップで SKILL.md に収束させ、2 回走らせて、手書きより安定するか見てみてください。