「このプロンプト、誰が作ったんだっけ?」
「なぜこの部分があるのか分からない」
「ちょっと修正したら、全然違う出力になってしまった」
こんな経験はありませんか。
チームでAIを活用していると、必ずぶつかる問題です。
プロンプトは「ただの文章」として扱われてきました。
でも、それが間違いだったのです。
プログラムにプログラミング言語があるように、プロンプトにも言語が必要でした。
その答えが、Thomas Ager博士が開発した「(: Smile」です。
2年以上のプロンプトエンジニアリング経験から生まれた、オープンソースの構造化言語なのです。
プロンプトの「読めない」問題がついに解決
HTMLがウェブサイトを構造化するように、(: Smileはプロンプトを構造化します。
これまでバラバラだったチームのプロンプトが、統一された形式で管理できるようになるのです。
基本的な仕組みはシンプルです。
テキスト絵文字((:、[;、[=など)を使って、セクションを開いたり閉じたりします。
例えば、こんな感じです:
- セクション開始:(: セクション名 (
- セクション終了:) セクション名 🙂
たったこれだけで、LLMはプロンプトの構造を理解しやすくなります。
実際に動作する例を見てみよう
まずは最もシンプルな例
最も基本的な(: Smileの使い方です。
(: 指示 ( ユーザーの質問に丁寧に答えてください。 専門用語は避けて、分かりやすく説明してください。 ) 指示終了 🙂
これだけでも、プロンプトの意図が明確になります。「指示」というセクションがあることで、LLMは何をすべきか理解しやすくなるのです。
データと指示を分離する例
より実用的な例を見てみましょう。データと処理指示を明確に分離します。
(: 処理指示 ( 以下のテキストを要約してください。 重要なポイントを3つ挙げてください。 ) 処理指示終了 🙂 [: 入力データ [ ここに要約したいテキストを入れます。 例えば、会議の議事録や記事の本文などです。 ] 入力データ終了 :]
このように構造化することで、「何を」「どうするか」が一目瞭然になります。
出力形式を指定する例
出力の形式を細かく制御したい場合の例です。
(: タスク定義 ( 製品レビューを分析してください ) タスク終了 🙂 [: 出力形式 [ ## 分析結果 - 良い点:{3つ箇条書き} - 改善点:{3つ箇条書き} - 総合評価:{5段階評価と理由} ] 出力形式終了 :] (: 分析対象 ( [ここに製品レビューのテキストを入れる] ) 分析対象終了 🙂
{} で囲まれた部分は、LLMが埋めるべき箇所を示しています。
これにより、常に同じ形式で結果が返ってきます。
なぜこれまでの方法では失敗したのか
従来のプロンプト管理には、致命的な問題がありました。
問題1: 意図が不明確
長いプロンプトになると、どの部分が何のためにあるのか分からなくなります。
コメントを書いても、それ自体がLLMへの指示と混同される恐れがありました。
問題2: 修正の影響が予測不能
一部を変更すると、全体の出力が変わってしまうことがあります。
どこまでが影響範囲なのか、事前に分かりませんでした。
問題3: 再利用が困難
良いプロンプトのパーツを他で使いたくても、切り出しが難しい。
結果として、似たようなプロンプトを何度も書き直すことになっていました。
(: Smileはこれらの問題を構造化によって解決します。
チームで使うと起こる3つの革命
- 誰でも読めるプロンプトになる
チーム全体が同じ構造で書くようになります。
新入社員でも、ベテランのプロンプトを理解できるのです。
引き継ぎの問題が解消されます。 - 知識が組織に残る
優秀なプロンプトエンジニアが退職しても大丈夫です。
(: Smileで書かれたプロンプトは、その意図と構造が明確だからです。
組織の知的資産として蓄積されていきます。 - 変更の影響が予測できる
プロンプトのどこを変更すると、出力がどう変わるか。
これが明確になります。
AIの判断根拠を説明する必要がある場合も、対応できるでしょう。
なぜ「笑顔」なのか?科学的な理由
(: Smileという名前には、深い意味があります。
研究によると、笑顔は脳内物質を分泌させます。
エンドルフィン、セロトニン、ドーパミン。これらが明確な思考を助けるのです。
さらに興味深い発見があります。
記号の 🙂 を見ただけで、脳の報酬系が活性化するのです。
つまり、(: Smileを使うたびに、脳は小さな報酬を感じています。
結果として、プロンプトエンジニアはより楽しく仕事ができます。
そして、より良いプロンプトを書けるようになる可能性があるのです。
あらゆるAIで使える汎用性
(: Smileの素晴らしい点は、どんなLLMでも動作することです。
対応済みのモデル:
- GPT-4o(OpenAI)
- Claude Sonnet 4(Anthropic)
- Gemini 2.5 Pro(Google)
- Kimi K2(Moonshot AI)
オープンソースモデルでも動きます。
企業の独自AIでも問題ありません。
この汎用性により、AIを切り替えてもプロンプト資産は維持されます。
今すぐ始める4ステップ
ステップ1: シンプルに始める
まず、既存のプロンプトにセクションを追加してみてください。
(: 入力データ ( と ) 入力データ 🙂 で囲むだけでも効果があります。
ステップ2: チームルールを決める
よく使うセクション名を統一します。
例えば:
- データ入力は必ず [: Input Data [
- 重要な制約は [! 重要 !]
- 厳密な指示は [= 厳密 =]
ステップ3: 効果を測る
構造化の前後で比較してください。
出力の一貫性はどう変わりましたか。
多くの場合、望まない出力が激減します。
ステップ4: 高度な機能を追加
変数 [$user_name$] や引用 [“正確にこの通り”] など、必要に応じて機能を追加していきます。
記号の使い分けガイド
(: Smileには用途別の記号があります。
適切に使い分けることで、より明確な指示が可能になります。
- (: ) 通常のセクション区切り
- [: ] より論理的で厳密なセクション
- [= =] 絶対に守るべき指示
- [” “] 一字一句そのまま出力
- [$ $] 後で置換する変数
- [! !] 特に重要な指示
- [; ;] 人間向けのコメント
- {} LLMが埋めるべき箇所
実践的な活用例:顧客対応プロンプト
実際の業務でどう使うか、具体例を見てみましょう。
(: 役割定義 ( あなたはカスタマーサポートの専門家です ) 役割終了 🙂 [! 重要な制約 !] - 丁寧な言葉遣いを維持 - 解決策を必ず提示 - 共感的な態度を示す [: 対応フォーマット [ 1. お客様の問題を要約 2. 共感の言葉 3. 具体的な解決策の提示 4. 追加サポートの申し出 ] フォーマット終了 :] (: 顧客の問い合わせ ( [$customer_inquiry$] ) 問い合わせ終了 🙂
このテンプレートを使えば、チーム全員が同じ品質の顧客対応ができます。
構造化の落とし穴を避ける
重要な原則があります。
「構造を増やせば良くなる」わけではないのです。
指示の実行が向上するなら構造を追加します。
逆に、シンプルな方が良い結果が出るなら、構造を減らします。
タスクとモデルによって最適なバランスは異なるのです。
過度な構造化は、かえって理解を妨げることがあります。
常に「これで本当に分かりやすくなっているか」を確認してください。
GitHubで今すぐ試せる
(: SmileはGitHubで完全無料公開されています。
ドキュメントも充実しており、すぐに使い始められます。
実際のプロンプト例も豊富に用意されています。
それらを参考にしながら、あなたの組織に合った使い方を見つけてください。
まとめ
プロンプトの共有問題は、もう過去のものになりました。
(: Smileという構造化言語が、その答えを提供してくれたからです。
チームの生産性が上がります。
知識が継承されます。
AIシステムの透明性も高まります。
そして何より、プロンプトエンジニアが笑顔で働けるようになるのです。
「ただの文章」だったプロンプトが、「構造化された資産」に変わる。
この変化が、あなたの組織のAI活用を次のレベルへと導くでしょう。
今すぐGitHubで(: Smileを試してみてください。
チームで共有できるプロンプトの時代が、ここから始まります。