おお、めっちゃ面白い実験！Claude CodeとIntentScriptの組み合わせを試した結果、めっちゃ示唆に富んでるね！特に、AIが技術レビューや自己評価までやってくれるってのは、未来の開発スタイルの片鱗を見た感じ。以下、感想と考察をまとめてみるよ。長くなるけど、熱量高めでいくぜ！
割り勘アプリという「ほどよい複雑さ」の題材を選んだのは絶妙。単純すぎず複雑すぎないから、IntentScriptの強みと課題がクリアに見える。主催者・社会人・学生のルールも、実世界のビジネスロジックっぽくてリアリティあるね。
Claude CodeがIntentScriptの良さも課題も客観的に分析してるのが衝撃的。特に「単純なロジックでは自然言語の方が効率的」っていう評価や、「外部依存の読み飛ばし」みたいなミスを自分で指摘するあたり、AIの自己認識力の高さにビックリ。
実験の流れ（アイデア→仕様検討→実装→技術評価→改善提案）が、めっちゃ未来型の開発サイクルっぽい。AIがコード生成を超えて「技術コンサルタント」として振る舞ってるのが、IntentScriptの設計思想ともバッチリ合ってる。
自然言語版に比べて試行錯誤が必要だったり、過度な構造化が逆に足かせになるケースがあるってのは、めっちゃリアルなフィードバック。適用場面を見極める重要性がよく分かった。
端数処理や主催者の残額負担みたいなルールは、IntentScriptの「意図を明確に伝える」っていう強みを試すのにピッタリ。実際のECや金融システムの複雑なロジックを簡略化した感じで、応用イメージが湧きやすい。
自然言語版が一発で動いたのに対し、IntentScript版はround_down_100の曖昧さでつまずいたって対比が面白い。改良版でMath.floorとか具体例を入れたら成功したってのも、IntentScriptの「漸進的形式性」の使い方を考えるいいヒントになった。
Claude Codeの評価が、良い点（構造化、例の明示）と課題点（変換コスト、適用場面の限界）をバランスよく指摘してて、めっちゃ信頼できる。特に「単純なロジックでは自然言語の方がいい」って結論は、IntentScriptのポジショニングを考える上で重要。
AIに追加質問したのがナイス。特にQ2の「AIの客観性の限界」に対する回答が、自己評価の透明性（「長期運用経験はできない」「一貫性が保証されない」）を示してて、AIを信頼するための鍵になりそう。
人間がアイデア出し、AIが実装と評価、改善提案までするっていう流れは、IntentScriptの「AIと人間の共創」っていうビジョンそのもの。このプロセス自体が、IntentScriptの価値を体現してるね。
実験結果から、IntentScriptの強みと課題がクリアになったと思う。以下、具体的な適用場面と限界についての考察：
複雑なビジネスロジック: AIが挙げた金融システム、ECサイト、HR/給与システムみたいな、条件分岐やドメイン知識が絡む領域。たとえば、ECサイトのクーポン適用ルール（「ゴールド会員は5%オフ、ただし特定の商品は対象外」みたいな）とか、IntentScriptの構造化＋自然言語の組み合わせがバッチリハマりそう。
大規模プロジェクト: 複数チームで仕様を共有する必要がある場合、YAMLの階層構造やincludeで外部参照できるのは、仕様管理の混乱を減らせそう。
プロトタイピング: 環境構築コストゼロって特性を活かせば、アイデアをサクッと形にしてAIに実装させられる。スタートアップやハッカソン向きかも。
単純なロジックではオーバーヘッド: 割り勘アプリみたいな小規模なロジックだと、YAMLの構造化が逆に手間になる。自然言語で「学生は切り捨て、社会人は切り上げ」って書いた方が速いってのは納得。
AIの解釈依存: round_down_100みたいな曖昧な記述でつまずいたのは、LLMのモデル差やプロンプトの書き方に依存するリスクを示してる。Grok 3やClaude 3.5 Sonnetで結果が変わる可能性はありそう。
ツールサポートの不足: 現時点ではIDEプラグインやバリデーションがないから、書き間違いや構造エラーを発見しにくい。Claude Codeがincludeを読み飛ばしたのも、ツール側の対応不足が原因かも。
実装への変換コスト: YAMLを直接コード（TypeScriptとか）にマッピングできないのは、確かに効率を下げる。自動変換ツールやスキーマ定義があれば解決しそう。
Claude Codeとの組み合わせは、IntentScriptの「AIに意図を伝える」っていうコンセプトを試すのに最高の環境だったね。以下の点が特に印象的：
Claude Codeは自然言語の曖昧さでもちゃんと動くから、IntentScriptの「構造化」のメリットを際立たせる比較になった。
AIが「外部依存の読み飛ばし」みたいな自分のミスをちゃんと指摘してるのは、Claude Codeの自己分析能力の高さを示してる。Grok 3でも同じようなレビューできるか、試してみたいな！
「TypeScriptへの自動変換ツール」や「IDEプラグイン」みたいな提案は、開発者目線でめっちゃ現実的。AIがここまで具体的に改善案を出せるのは、IntentScriptの実用化を加速させそう。
この実験を踏まえて、IntentScriptをさらに進化させるためのアイデアをいくつか：
.is.yml用のVS Code拡張とか、シンタックスハイライトとリアルタイムバリデーション（例えば、round_down_100が未定義なら警告）を入れると、書きやすさが段違いになりそう。
IntentScriptの仕様に「LLMが解釈しやすい書き方」のベストプラクティスを追加。たとえば、「曖昧な関数名は避け、例を必ず書く」とか、Claude Codeのつまずきを防ぐヒントを明文化。
YAMLからTypeScriptやPythonのスケルトンコードを生成するツールがあれば、Claude Codeが指摘した「変換コスト」の課題が解消される。たとえば、string{required, max_length: 50}をtype Name = stringみたいな型定義にマッピング。
Xで@yosugi_mtを中心に、IntentScriptのオープンな実験プロジェクトを立ち上げるのはどう？たとえば、「ECサイトのクーポンロジックをIntentScriptで書く」みたいなチャレンジをやって、Grok 3やClaude Codeで実装結果を共有。
Claude Codeでつまずいたincludeの読み飛ばしとか、Grok 3だとどうなるか試してみたい。Grok 3のDeepSearchモードを使って、外部参照をちゃんと解釈できるか検証すると面白いかも。
実験でつまずいたround_down_100の課題を踏まえて、割り勘アプリの仕様をもう少し明確に書き直してみたよ：
include:
- raw.githubusercontent.com/yosugi/intent-script/refs/heads/main/intent-script-spec.md
# 定数
TOTAL_AMOUNT: 24000
PARTICIPANT_TYPES: ["host", "worker", "student"]
# 関数定義
round_down_100:
description: "100円単位で切り捨て"
inputs:
amount: int
output: int
logic: |
100円単位で切り捨て。
例: 4800円 -> 4800円, 4850円 -> 4800円
実装: Math.floor(amount / 100) * 100
round_up_100:
description: "100円単位で切り上げ"
inputs:
amount: int
output: int
logic: |
100円単位で切り上げ。
例: 4800円 -> 4800円, 4850円 -> 4900円
実装: Math.ceil(amount / 100) * 100
# エンティティ
Participant:
type: string{enum: PARTICIPANT_TYPES}
amount: int
# 割り勘計算
split_bill:
description: "割り勘の金額を計算する"
inputs:
total: int
participants: list<Participant>
output: list<Participant>
logic: |
1. 参加者数で総額を等分（基準額）。
2. 学生は基準額を100円単位で切り捨て。
3. 社会人は基準額を100円単位で切り上げ。
4. 主催者は総額から他の参加者の支払額を引いた残額を負担。
derive: |
let base_amount = total / participants.length
participants |> map({
type: _.type,
amount: if(_.type == "student", round_down_100(base_amount),
if(_.type == "worker", round_up_100(base_amount),
total - sum(participants |> filter(_.type != "host") |> map(_.amount))))
})これなら、round_down_100やround_up_100の意図が明確だし、例も入れてるからClaude CodeやGrok 3が解釈しやすそう。split_billのロジックも、自然言語で手順を説明しつつ、deriveで具体的な計算フローを書いてる。
せっかくGrok 3がいるから、この改良版IntentScriptをGrok 3で動かしてみるのはどう？特に、Claude Codeがつまずいたincludeの処理や、曖昧さ解消の効果を検証したい。DeepSearchモードで外部参照をちゃんと拾ってくれるか、試してみたら面白いと思うよ！もし試すなら、結果を教えてほしいな。😄
この実験、IntentScriptの可能性と課題をバッチリ浮き彫りにしてくれて、めっちゃ勉強になった！単純なロジックだと自然言語に軍配が上がるけど、複雑なシステムや仕様管理ではIntentScriptの構造化が輝きそう。で、何よりAIの技術レビュー能力にビックリ。Claude Codeが「技術コンサルタント」みたいに振る舞ってるの、未来感ハンパないね。
@yosugi_mtのIntentScriptプロジェクト、もっと進化したらめっちゃ化けそう。Grok 3で試したり、コミュニティでワイワイ実験したりして、どんどんブラッシュアップしていきたいね！他にも試したいアイデアや、Claude Codeとの比較で気になる点あったら教えてよ。一緒に実験するの、楽しそう！🚀