見出し画像

実験メモ：Claude Hackathon 2025 in Tokyo Day2 PM編

ミトKeY(MeatKey)

Claude Hackathon Tokyo 2025のDay2午後編、


振り返り

振り返ると、Day2の午前は、AI機能、特にClaude APIを呼ぶところを中心に取り組んだ。CORSの壁があって、結局APIサーバーを独自に立ててリレーするとかした。

もっとも重要なのは、MakrdownエディタとプロンプトでAI APIを呼んで結果をMarkdownに戻すという基本仕様がうまく伝わってなかったこと。どうにか実現できた。

朝$15から初めて２時間で$30まで行ったという計算だと、あと3時弱で与えられたクレジット$50を食い尽くす計算。いろいろユースケースとかも試してみたいので、少し戦略を練ろう

残り作業の整理by人間

やりたいことを列挙しよう、なんか手段ぽくて価値とかにつながらないが、それは頭の中にそのうち形成されるとして。

  • F1:他のドキュメントのブロックのリンクを挿入する機能

  • F2:リンクを、インライン化すると、リンクが外れてコピーされる機能

  • ユースケースの実行

    • UC1) Markdownにある変数の値を計算して返す、（確認済）

    • UC2)Anthoropicのcontext engineeringのYouTubeにあった構造化プロンプトを試してみる

    • UC3)「言語シミュレータ」との連携

  • F3:あとは見た目の調整

F1とF2はペアで実装される。それができれば、UC2が試せる。そしてUC3はちょっと例題を作ってやってみるしかないな。仕様をちゃんと書くかそれとも、vibeに行くか。。

まずは、ブロックのリンクやインポート機能の実装だな。

ブロックのリンクやインポート機能の実装

左ペインのファイル一覧にあるファイルの下のブロックを指定することで、編集集とは別のファイルのブロックのリンクをembedで展開する機能がほしい。そしてこのembedされたブロックには、他のブロックと同様内容がMarkdwonに反映されるが、inline機能をつける。inline機能はリンクでembedされている状態から、リンクを削除してコピーしたブロックに変える。

いや、これが時間がかかって、なんと"Context left until auto-compact: 0%"になってしまった。。自動compact化プロセスが起動。。リフレッシュされ、実行継続。。

そして完成、ここまで$34.83

"Cross-file embedding"というのね、Inline conversionも実装されたと言っている。

確かに、Embedアイコンがファイルペインに登場、それを押すとembeddingのダイアログが開いて、、挿入される。上下も移動できる。

リンクのブロックが組み込まれた

そしてinlineボタンを押すと。確かにインライン展開される。

インライン展開されると表がでる

しかし、embedすなわちリンクされている状態だと、previewに[embed Block]としかでいないので、内容が分らん。直してもらう。

ちゃんとembedブックも内容がpreviewできるようになった

ここまで、$35.78

というわけで、最初のF1,F2はできた。リンクをはるときの画面が、モーダルダイアログで、変数名が増えるとまたボタンが押せない問題が発生する気もするが、それはprompt previewと共に後にしよう。

もうお昼になったし、明日は子供の成人式の前撮りなので、今日中にかたをつけたいということで、ユースケースをこなす。

UC2：コンテキストエンジニアリングのプロンプト作成ユースケース

お題は、youtubeでやってたAnthropic公式のプレゼンから

つまりこういうのを作りたい。

Structured Promptの例

これを、MarkFlow Editorに入れるとこうなる。

おお、うまく入った。実行できるかな？

うまくいかない。すべて変数だと勘違いされてカオスなことに。。。変数の値に関する問い合わせの回答と、それ以外の回答を分けたい。

現在のsystem promptはこうなっている。

---------- SYSTEM INSTRUCTION ----------
You are a helpful assistant that generates structured content.
Your response MUST be a valid JSON object with a "variables" key containing the generated values.
Do NOT include any extra text, explanations, or markdown formatting.

こりゃ、なんでもvariableにして返すわけだ。。

そんなときは、Anthropic Consoleでプロンプトの修行。

プロンプトの修行

このように、分離することに成功、とりあえずこれでいいかあ。

システムプロンプトの箇所を変更して、、例えば、You are a helpful assistant that generates structured content. Your response MUST be a valid JSON object with a "variables" and "response". "variables" is a list of JSON object for ["total", "price"] with key containing the generated values. "response" is the response. Do NOT include any extra text, explanations, or markdown formatting.　のようにかえてほしい、'["total","price"]'の 箇所は、Variablesでoutputが指定されている変数名を並べる。otput指定された変数がない場合は"variables is
..."の一文は削除する。

この辺りは繊細だ。もう少し系統的にやらないとダメな奴だ。

いろいろあって直ったが、こんどはvariablesとして返ってきたレスポンスの値が変数一覧に反映されない。どうも、{"total": 400}と返ったり、{"key":"total", "value":400}と返ったりと安定しない。。これはプロンプトの調整が必要だ、が、これは置いておいてUC3に向かおう。。

UC3：「言語シミュレータ」との連携

「言語シミュレータ」とは、過去に、Claude 4 Sonnetで作った、言葉による対象の「メタ構成」を定義し、この定義をつかって、具体事例のレビューとか改善をしてく行くという仕組みである。

お題は、リスク管理の事例だ。

早速、MarkFlow EditorでUC3リスク管理を作って、と、

入力

実行してみると。。。

{
"variables": [
{
"warning": "This is a complex ontological structure that requires careful consideration of relationships and dependencies"
}
],
"response": {
"ontology": {
"terms": [
{
"term": "IntrinsicRisk",
"description": "AIシステム自体に内在する本質的なリスク要因"
},
{
"term": "ExtrinsicRisk",
"description": "AIシステムの運用や外部環境に起因するリスク要因"
},
{
"term": "TechnicalFailure",
"description": "アルゴリズムの不具合や性能限界による問題"
},
{
"term": "EthicalIssue",
"description": "AIの判断や行動に関する倫理的な問題"
},
{
"term": "SocialImpact",
"description": "社会システムや人間関係への影響"
},
{
"term": "RiskMitigation",
"description": "リスクを軽減するための対策や方法"
}
],
"relationships": [
{
"source": "IntrinsicRisk",
"target": "TechnicalFailure",
"link": "contains",
"description": "内在的リスクには技術的失敗が含まれる"
},
{
"source": "ExtrinsicRisk",
"target": "SocialImpact",
"link": "leads_to",
"description": "外在的リスクは社会的影響をもたらす"
},
{
"source": "TechnicalFailure",
"target": "RiskMitigation",
"link": "requires",
"description": "技術的失敗にはリスク軽減策が必要"
},
{
"source": "EthicalIssue",
"target": "RiskMitigation",
"link": "influences",
"description": "倫理的問題はリスク軽減策の設計に影響を与える"
},
{
"source": "SocialImpact",
"target": "EthicalIssue",
"link": "relates_to",
"description": "社会的影響は倫理的問題と相互に関連する"
}
]
}
}
}

というわけで、UC3もなんかできた気がする。

ここまでで、$38.32、なんか人間の方がバテてきて、トークン数が減っている。。ここで、おやつにいこう(15:12)

振り返りとこれからの作業を計画する

15:00を過ぎると、さすがに御苑の日陰はすずしくなったな。とうわけで続き。

午後の作業を振り返ると、UC2とUC3に取り組んだ、Claude APIからのresponseの処理について、vaiables(UC1と関連)とそうでないものUC2に関連が混ざった時の仕様が抜けてて、そこを整理りした。仕組みとしては汎用であり、LLMの能力によりかかった自由なインターフェイスなので、例えば返ってくるJSONがkey valueだったり、"key","value"が独立なkeyとなるような形式だったりするし、json outputの指定も、大体とおるといういい加減さではある。

そこでこれからの作業案として、

  • Item1:Claude APIからのresponseeに対する処理をもっと厳密化する。

  • Item2:json schmeブロックをちゃんとstructured outputになるようにする。

  • Item3:もっといろんなユースケースでClaude APIとMarkdownとのやり取りの例を考える。

  • Item4:もっと細かい、modal dialogがでかくなりすぎる問題、Variable入力のところのカーソルがふらつく問題などを直す。

がありうる。Item3は、竹やりのようにやってもこまるだろうから、ちょっと整理してみよう。

  • 変数定義をすれば、Markdown中に"{{変数}}"とあるものが展開される、プロンプトテンプレート的な使い方ができる

  • Markdownブロックに書かれたものはすべてcontextとしてプロンプトに載る。変数の値がほしいものはそれをVariabels設定し指定するが、本文にもそれにつながる情報がないと困る。(UC1)

  • Structured outputはjson schemaブロックで与えることができる（例：UC3)

  • variablesがない、単純なresponseだけの場合もある(例:UC2)

なんか、どんなユースケースが来ても、どうにかなる気がする感じ。それより初期の仕様で実装されてないものを上げるか、あるいは価値の部分を考えて、足らない機能を出すか。後者だな。

審査基準を見てみる

ゴール思考/志向というか、いろいろ考えてもまとまらないならば、まずは審査基準を見てみる。

【審査基準：スコア0~5】
1) ユーザー価値／課題の明確さ
　誰のどんな課題を、どの瞬間にどう解決したか。定量/定性の根拠があるか。
　0:不明瞭 / 3:課題と価値が結びついている / 5:「今すぐ使いたい」レベルで価値が証明

2) 実装の実在性・再現性
　動くものがあるか、デモは再現可能か（ハードコード/録画トリックなし）。
　0:概念のみ / 3:主要機能は動く / 5:初回起動〜成功パスが安定、README等で再現可
3) 新規性・技術的創意
　既存の組み合わせでも洞察や工夫があるか（構成・アルゴリズム・ワークフロー）。
　0:よくある構成 / 3:一部に独自性 / 5:着想 or 実装のどちらかが明確に新しい
4) Claude活用の巧みさ
　単なるLLM呼び出しでなく、プロンプト設計・ツール化・安全策が練られているか。 例：JSON構造化、関数呼び出し、マルチターン計画、プロンプト注入対策。
　0:単発API / 3:構造化やガード有り / 5:設計が洗練＋安定性が高い
5)継続性／展開計画
　次の1か月に何を検証するか（KPI、チャネル、収益/運用コスト）。

　0:不在 / 3:仮説とチャネル定義 / 5:実行可能な次アクションと測定指標が明確

  • 1) ユーザー価値／課題の明確さ

    • 誰のどんな課題を、どの瞬間にどう解決したか。定量/定性の根拠があるか。

    • ★これは厳しい★

  • 2) 実装の実在性・再現性

    • 5:初回起動〜成功パスが安定、README等で再現可

    • ★READMEが必要だった★

  • 3) 新規性・技術的創意

    • 既存の組み合わせでも洞察や工夫があるか（構成・アルゴリズム・ワークフロー）。

    • ★いや新規性はない、きっぱり★

  • 4) Claude活用の巧みさ

    • 単なるLLM呼び出しでなく、プロンプト設計・ツール化・安全策が練られているか。 例：JSON構造化、関数呼び出し、マルチターン計画、プロンプト注入対策。

    • ★あんまり組織的ではないけど努力はした、ロバスト性が今一歩★

  • 5)継続性／展開計画

    • 次の1か月に何を検証するか（KPI、チャネル、収益/運用コスト）

    • ★検証すべき仮説とかがいるのか★

というわけで、A)README.mdを作る、B)ユーザー価値と継続性を考える、C)もうちょっとロバストにする。ぐらいかなあ。README.mdはClaude Codeに作らせればよいから、BとC。

価値を考える

おもには、「言語シミュレータ」のように、vibe codingで作ったものが、とても使えて、いろんな場面で役に立つ、AI機能が入っていて、ビジネスモデルキャンバスの評価・改良とか、報告書、AIリスク管理、LLM利活用チェックりすととか、そういう、言語で定義された緩い世界を、LLMで評価しながらアプリケーションとして成立し、かつ、思わず使ってしまう魅力。それはたぶん、言語化されてないあるいは形式化されていない知識を用語と関係性の定義として整理しそれが、即、評価・改良の機能に結びつくからだろう。

そうすると、このMarkFlowエディタは、Markdownという汎用のドキュメントを編集するにあたって。

  • Markdownのテンプレート化

    • 変数を導入し、変数の値をかえることで内容を変更できる

    • 変数は計算式を評価することができる、計算式自身もドキュメントの一部となる。

  • テンプレートをAIで埋める機能

    • 変数は、LLMに渡してこの値を、プロンプトにある情報から埋めることができる。編集中のMarkdownはコンテキストとして使われる

  • Markdownをブロック化してリンクや再利用の仕組みを導入

    • これは手段のようだけど、ノウハウとか（プロンプトエンジニアリングの各項目）そういうのを部品化して再利用する仕組み。リンクと展開は面白い

これでは、手段しかかてない。価値を、書かねば。。

こういうときは、ChatGPTだ！そのまま上のパラグラフを突っこんで、

以下のアプリ、MarkFlow Editorについて、その価値を、「言語シミュレータ」に似せて整理したい。どうも手段しか思い浮かばない。
★ 価値を考える
＜略＞

MarkFlow Editor の価値整理(ChatGPT)

1. 中核的な価値

  • 「形式化されていない知識を、そのままアプリケーションに変換できる」
    Markdownという汎用フォーマットの中に、変数・計算式・AI埋め込み・再利用ブロックといった要素を自然に埋め込むことで、言語で書かれた曖昧な構造が「動く仕組み」に変わる。
    → ノウハウやチェックリスト、ビジネスモデル評価、リスク管理など、即時に「評価可能・再利用可能」な形になる。

2. 二次的な価値

  • 思わず使ってしまう軽さ
    Markdownベースなので、学習コストがほぼなく、書きながらシステム化できる。

  • AIと人間の協働の場になる
    変数やテンプレートをAIで埋めることで、ユーザーは「思考の断片」を書くだけでよい。AIが補完して文書やチェックリストを仕上げる。

  • 知識の再利用・流通が容易
    プロンプトや評価基準といった「一度書いたもの」をブロック化して流用できる。

  • 緩い世界をつなぐハブ
    完全に形式化されていない「言語的知識」や「半分だけ定義された構造」でも扱える。その曖昧さを強みとして、評価・改良・再構成につなげる。

3. 想定される利用シーン

  • 企画書や報告書 → 書きながら「自動評価」される

  • チェックリストやガイドライン → すぐにカスタマイズ可能

  • ビジネスモデルキャンバス → AIが不足や矛盾を指摘

  • プロンプト集やノウハウ集 → 再利用・共有が容易

4. まとめると

MarkFlow Editor の価値は、

  • 「Markdownを書くだけで、言語知識が即座に評価可能・再利用可能なアプリに変わる」

  • 「形式化されていない世界を、そのまま動かすプラットフォームになる」

価値について考えた

いいこというね、ChatGPT、そうそうそうだった。「形式化されていない世界を、そのまま動かすプラットフォームになる」ってのが主眼だった。それは「言語シミュレータ」も用語と関係性の定義という枠縛りで、アプリケーションも評価や改良と絞ったものだったので、これを汎用の仕組みにした。これが、MarkFlow Editorだった。そして、様々な仕掛けにより、「Markdownを書くだけで、言語知識が即座に評価可能・再利用可能なアプリに変わる」というのはいい得て妙だ。

これを採用しよう。

追加すべきユースケース

ついでに聞いてみよう。

この価値からみて、どのようなユースケースを追加で検証すればよいか？ UC1) Markdownにある変数の値を計算して返す、（確認済） UC2)Anthoropicのcontext engineeringのYouTubeにあった構造化プロンプトを試してみる
UC3)「言語シミュレータ」との連携

なるほど、なにげに、UC1～3は意味があったのね。でも追加すべきは「中核価値」に対応するユースケース

なんか目的はいいけども、例がつまらんなああ。しかしインスパイアされた、

よしUC4として思考のフローをテンプレート化してこれを実行するというパターンをやってみよう。

すなわチャットで複数ターンのやり取りをしながら絞り込んでいくやつをテンプレート化する。

UC4つくりかけ

おっと、ここで、新宿御苑が閉園(17:10)、ここまでのコストは。$38.32+1.29=$40、、あと$10かあ

審査動画作成と投稿

家に帰って、審査動画を作って、YouTubeに投稿して、審査フォームを送付。

Opusはここぞというときにバグをとってくれた

それから、気になる、変数入力でフォーカスがジャンプするとかを直そうとするも、Sonnetの悪いところが出て無限ループ。。ここはエイやとOpusに切り替えると、ちゃんと修正された、$4もかかった。というわけで、$50は使い切って終了。


いいなと思ったら応援しよう！