フロントエンドの表示コード（dataConverters.ts）を調査し、ブロックタイプごとにどのキーでテキストを読み出しているかを特定した。テキストブロックは content.text、コードブロックは content.code を参照している。API側（route.ts）は content をそのままJSONBに保存するだけなので、スキル側が正しい構造で送ればフロントで正しく表示される。バック...

2つの問題があった。1つ目: SKILL.mdにcontent JSONの具体的なキー名が未記載で、AIが content: "テキスト" のような文字列直接渡しや content: { body: "..." } のような間違ったキーで送信していた。DBにはJSONBとしてそのまま保存されるのでエラーにならず、フロントで空表示になる「サイレント失敗」パターン。2つ目: 有効なsection値は ...

外部APIを設計するとき、スキーマの「例」を省略するとAIエージェントが誤った形式でデータを送る。特にJSONBのような自由度の高いカラムでは、バリデーションで弾けない不正構造がサイレントに保存されてしまう。対策: (1) APIドキュメントやスキル仕様書には必ず完全なリクエストボディ例を含める (2) 有効な値のホワイトリストを明記する (3) 1セクション1ブロックのような暗黙の制約もドキュメ...

最初は「AIセッションログをそのままインポートする」案が出たが、APIキーや社内URLなどの機密情報が混入するリスクが致命的だった。生ログではなく「Claudeがセッションを分析して要約を生成する」アプローチに切り替えた。

技術的には3層構成にした:

1. Lovai側にREST API (POST /api/posts/external-create) を新設 — APIキー認証、シークレット...

3つの想定外があった:

1. ミドルウェアが先にブロックする /api/postsで始まるパスがSupabaseミドルウェアのcookie認証で保護されていた。APIキー認証のエンドポイントはミドルウェアをバイパスする除外設定が必要だった。

2. RPCの戻り値が [object Object] RPCが返すJSONBを { id: string } として型キャストしていたが...

APIキー認証の全体フロー:

Authorization: Bearer [REDACTED] → extractBearerToken (prefix検証) → hashApiKey (SHA-256) → DBでハッシュ照合 → userId取得 → レート制限チェック → 入力バリデーション + シークレット自動除去 → Stripe Connect状態チェック (...

Lovaiの有料コンテンツ保護設計で、まさにこの問題にぶつかりました。

AIが提案してきたのは「メタデータごと隠す」設計。タイトルも概要も何も見せない。技術的には正しい。セキュリティ的にも最も安全。AIに「問題ある？」と聞いたら「適切にデータが保護されています」と返ってきました。

でも、購買心理を知っている自分には最悪の設計に見えました。ユーザーが買うかどうか判断するには、「何が書いてあるか」...

nthropicの実験で面白かったのは、評価するAIすら最初は甘かったということ。「クロードは初期状態ではQAエージェントとして不十分」とAnthropic自身が認めています。

つまり、AIを評価するAIですら、人間が基準を設計して調整しないと動かなかった。

コードが書けない自分は、AI開発で不利だと思っていました。でもAnthropicの3エージェント構造（プランナー→ジェネレーター→評価者...

Lovaiに自動翻訳機能を入れました。日本語で投稿したら英語版が自動で作られる仕組みです。

最初に時間をかけたのは翻訳の精度でした。どのAIモデルを使うか、プロンプトをどう書けば技術用語が崩れないか。「翻訳機能なんだから、訳の質がすべてだろう」と思っていたんです。

ある朝、スマホにエラー通知が何十件も来ていました。翻訳が微妙とかじゃなくて、機能が丸ごと止まっていた。

原因を調べたら、AIが返...

**精度より先にデータ形式を固めるべきだった。**精度の調整に使った時間より、データ形式の防御に丸1日かかりました。精度はモデルを変えれば後からいくらでも上がる。でも壊れたときの復旧の仕組みがないと、改善の実験すらまともにできません。

高機能ツールを調べすぎて遠回りした。 メッセージキューの比較に半日使いましたが、必要だったのは「失敗したらリトライ、経緯が見える」だけでした。要件に対して...

Lovaiに動画投稿の機能を入れたとき、最初はSupabase Storageにmp4をそのまま置いていました。画像と同じ感覚で。

これがびっくりするくらい遅かったんですよね。

数十MBの動画をアップロードするだけで体感10秒以上。再生しようとするとバッファリングで数秒待たされる。どのSNSでも動画は当たり前にスムーズに流れてくる時代に、自分のサービスだけぐるぐるローディングが回っている。個人...

Before: ブラウザ → サーバー → Cloudflare Stream。ファイルがサーバーを経由するので、ユーザーの回線が速くてもサ変えたのはアップロードの経路です。

Before: ブラウザ → サーバー → Cloudflare Stream。ファイルがサーバーを経由するので、ユーザーの回線が速くてもサーバーの処理速度で頭打ちになる。

After: ブラウザ...

一番のトレードオフは帯域が2倍になること。200MBの動画なら合わせて約400MB分の通信が発生します（概算）。

最初はもっとシンプルに、ブラウザのObjectURL（ローカルプレビュー）でごまかせないか考えました。でもSNSだから、投稿した瞬間に他のユーザーのフィードにも流れてくる。自分のブラウザでしか見えないプレビューでは意味がない。誰からでもアクセスできるURLが必要で、結局二重アップロー...

LovaiにDM機能を実装した直後に気づいたことがあります。

「ちょっと質問したいDM」と「一緒に何かやりたいDM」が同じスレッドに混ざると、受け取る側が困る。「これ軽い話？ 真剣な話？」がわからなくて、返事のテンションが定まらない。

PMとして案件をいくつもやってきた中で、「目的が違うコミュニケーションを1つの場所に押し込むとどっちも中途半端になる」というのは何度も見た光景でした。

だから...

最初にAIに「オファー機能を作りたい、ステータス遷移もほしい」と投げたら、オファーテーブルにUPDATEのRLSポリシーを書く設計が返ってきました。「受信者だけがpending→acceptedに変更できる」というルール。

これ、一見正しそうなんです。でもよく見ると穴がありました。

RLSは「どの行を更新できるか」は制御できるけど、「どの列を更新できるか」は制御できない。ステータスを更新するつ...

一番ハマったのは、RLSの限界に気づくまでの時間です。

AIが出してきたUPDATEポリシーの設計は、読んだ瞬間は「これで完璧だ」と思いました。USING句とWITH CHECK句の組み合わせで遷移ルールが表現されていて、美しかった。

でも「本当にこれで安全？ 他の列は触れない？」と聞いたのがきっかけで列範囲問題が出てきた。RLSは行レベルの制御しかできないという、言われてみれば当たり前の制約...

「ユーザーが自分のコンテンツを売って稼げる」仕組みを作りたくて、Stripe Connectを導入しました。

以前に別のサービスで導入した経験があって、そのときは審査もすんなり通ったんです。だからLovaiでも同じ感覚で進めていたんですが、正直甘く見ていました。

ある日、Stripeからメールが届きました。Lovaiのアカウントが「アグリゲーション」（禁止業種）に該当するため、対応できないと。...

諦めるわけにはいかなかったので、サービスの詳細を改めて説明するメールを送りました。

教育サービスとデジタルコンテンツのカテゴリに該当すること。利用規約でアダルトや著作権侵害、情報商材を禁止していること。noteやGumroad、Patreonと同様のビジネスモデルであること。できるだけ具体的に、審査する側が判断しやすいように書きました。

さらに、Connectを使わない代替案（Lovaiが販売...

この経験で一番学んだのは、Connect申込書の提出タイミングです。アカウント開設と同時期に出しておかないと、意図しない判定を受ける可能性があります。しかも審査のロジックは非公開なので、後からしか理由がわかりません。

もう一つ。サービスが複雑になるほど、審査側への説明コストが上がります。以前のサービスは「クリエイター支援」というシンプルなモデルだったのですんなり通りましたが、Lovaiのようにブ...

Lovaiの投稿はブロック単位で公開レベルを設定できる。public（無料）、premium（有料）、private（非公開）の3段階。

この仕組みを作ったのは、「記事全体を有料にする」モデルに違和感があったから。タイトルと冒頭だけ見えて残りは課金、という構造だと、買うまで価値がわからない。読者にとっても投稿者にとっても損。

ブロック単位なら、きっかけは無料で共感を生み、やったことは有料で価値...

投稿データを3テーブルに分離して、Supabase RLS + Security Definer関数で三層防御を構築した。

テーブル分離

• post_blocks（メタデータ）── 公開レベルやプレビューテキスト。誰でも見れる
• post_block_contents（コンテンツ本体）── RLSで保護される核心
• post_purchases（購入履歴）── ユーザー...

購入レコードの設計ミス 最初はINSERTだけ塞いでUPDATEは開けていた。これだとstatusをpending→completedにユーザーが書き換えて、決済なしで有料コンテンツが見れてしまう。AIに「本当に安全？」と聞き直して発覚した。全操作を塞ぐのが正解。

Security Definerの危うさ 最初はrow_to_json(p.*)でpostsの全カラ...

Lovaiを開発する中で、UIの生成を何百回とAIに依頼しました。

コードは一発で動くことが多いです。ロジック、API連携、データベース操作。これらは指示が明確なので、AIは正確に書いてくれます。でもUIは違いました。

「いい感じのカードコンポーネントを作って」と指示すると、毎回「整ってはいるけど、なんか違う」ものが出てきます。動くけど、使いたくならない。見た目は綺麗だけど、触りたくならない。...

実際に出した指示のBefore/Afterを5パターン紹介します。

パターン1：サイズと余白

指示内容 ❌ 伝わらない 「もう少し余白を広げて、テキストを大きくしてください」 ✅ 伝わる 「カードのパディングを上下24px・左右20pxに。タイトルを18px→22px、line-height 1.6に」

「もう少し」「大きく」はAIにとって曖昧すぎます。人間同士なら画面...

1つ目。数値で指示するには、自分の中に基準が必要です

「余白を24pxにして」と言うには、24pxがどのくらいの広さかを知っていないといけません。自分の場合はデザインの経験があったので数値感覚がありましたが、そうでない人はまず好きなサービスの画面をブラウザの開発者ツールで観察するのがおすすめです。

目安として、余白なら小が8〜12px、中が16〜24px、大が32〜48px。本...

SNSにシェアしたとき、表示されるカード画像（OGP）が全員同じデザインでした。タイトルとアイコンが機械的に並んでいるだけ。

これがずっと気になっていました。

SNSのタイムラインで目に入る時間は一瞬です。その一瞬で「この投稿、読んでみようかな」と思わせるには、カード画像の印象が大きい。同じテンプレートが並んでいると、どの投稿も同じに見えてスルーされます。

多くのプラットフォームでは、OGP...

作ったのは、3つのレイヤーでOGPの見た目を自分好みに変えられる仕組みです。

1つ目のレイヤーはテーマ選択です。レイアウトそのものを3種類から選べます。

Editorialは太い枠線と力強い左寄せのタイポグラフィで、プロフェッショナルな雰囲気です。Recipe Cardは清潔感のあるレイアウトで、右側に大きなアクセントカラーのバーが入ります。Accentは上部に細いカラーバーだけのシンプル・...

1つ目。SNSのキャッシュが強すぎる問題です。

OGPの設定を変えても、SNS側はOGP画像を長時間キャッシュします。設定を変更したのに古いデザインが表示され続けます。

対処として、OGP画像のURLにタイムスタンプパラメータを付けるようにしました。投稿の更新日時とOGP設定の更新日時のうち新しいほうをURLの末尾に付加します。設定が変わるとURLが変わるので、SNS側は新しい画像として取得...

AIを使ってデザインを納品するのが当たり前になった。でも契約書のフォーマットが追いついていない。

実際にあったこと。Figma MakeとMidjourneyを使ってLPのデザインを納品した。クライアントから数週間後に連絡が来た。「このデザインの素材、うちが自由に使い回していいんですよね？」

答えは「場合による」。AIで生成した画像の著作権がどこに帰属するかは、現行法ではグレーゾーンが多い...

契約書に追加すべき条項は5つのカテゴリに分かれる。

1つ目は「AI使用の開示と合意」。デザイン制作にAIツールを使用する旨をクライアントに事前に開示し、合意を得る条項。「使ってから報告」ではなく「使う前に合意」。

2つ目は「著作権の帰属」。AI生成物を含むデザインの著作権が、納品後にどこに帰属するかを明確にする条項。

3つ目は「成果物の品質保証範囲」。AIが生成した素材（画像、イラスト等）に...

条項1：AI使用の開示と合意

条文テンプレートはこうなる。「受託者は、本業務の遂行にあたり、画像生成AI、テキスト生成AI、UIデザイン支援AI等のAI技術を補助的に使用することがあります。AI技術の使用は、受託者の専門的判断に基づく創作プロセスの一部として行われるものであり、成果物の品質と独自性は受託者が責任を持って管理・担保します。委託者は、本契約の締結をもって、受託者によるAI技術の使用...

最近、自分が作ったデザインを見て「これ、AIが作ったやつと見分けつかないな」と思う瞬間が増えた。

Figma Make、Midjourney、DALL-E。どのツールを使っても似たようなUIが出てくる。クリーンで整ったレイアウト、8pxグリッドに忠実な余白、予測可能なカードコンポーネント、無難なグレーベースの配色。

これ自体は悪いことではない。ベースラインの品質が上がっているということ...

1つ目。クライアントに「雑じゃないか」と言われた。意図的に余白のリズムを変えたデザインを出したら「余白がバラバラに見える」と指摘された 。

対処法は、事前に「なぜこの余白にしたか」を1行で添えること。「セクション間にリズムをつけて、ユーザーの読む速度をコントロールしています」と書くだけで、「雑」が「意図的」に変わる。デザインの意図は、言葉にしないと伝わらない。

2つ目。崩しのテクニックは...

デザインにAIを使い始めた人が最初にぶつかる壁がある。「全部AIでいけるのでは？」と思った直後に来る「全部中途半端」問題。

Figma Makeでワイヤーを生成してみたけど、そのまま使えるクオリティではない。Opus4.6にUIの壁打ちをさせたら、言語化は鋭いけどビジュアルにはならない。結局、全部自分で作り直してる。

これは使い方が間違っている。

3つのツールには明確な「得意領域」があ...

1. Figma Makeに完成形を求めない Figma Makeが出すUIはそのまま納品できるレベルではない。これを理解せずに「AIが生成したのに使えない」と感じる人が多い。60点の叩き台を5分で出してくれるツールだと割り切ると、ストレスがなくなる。

2. Opus 4.6にビジュアルの判断をさせない 「この配色どう思う？」と聞いても、無難な答えしか返ってこない。Opus4.6が強...

2026年2月17日、FigmaとAnthropicが公式連携を発表した。

Claude Codeで生成したコードを「Send this to Figma」と入力するだけで、ブラウザのレンダリング状態が自動で編集可能なFigmaレイヤーに変換される。

これまでデザインの流れは一方通行だった。Figmaでデザイン → エンジニアがコード化。デザイナーが作ったものをコードに「翻訳」する作業。

そ...

自分のサービス（Lovai）の投稿作成画面を題材に、Claude Codeで実装済みのコードをFigmaに変換するワークフローを検証した。

手順はシンプルで、Claude Codeで対象コンポーネントのファイルパスを指定して、「このコンポーネントをブラウザでレンダリングして、Send this to Figmaで変換して」と指示するだけ。Figma上で編集可能なレイヤーとして取り込まれる。

...

1つ目。Auto Layoutが変換されない。これが一番の落とし穴。CSSのFlexboxはFigma上では絶対配置のグループに変換されることが多い。Auto Layoutとして認識させるには手動で設定し直す必要がある。構造が複雑なほど修正コストが高い。

2つ目。コンポーネント単位で変換するのが正解。ページ全体を一気に変換するとレイヤーが膨大になって扱いにくい。ヘッダー、カード、フォームなど...

Lovaiの投稿は4ステップで完成する:

Step 1 - 何を完成させた？ 成果物タイプ（開発 / 文章 / デザイン / 画像 / 動画 / 分析）を選ぶ。次に対象を選ぶ。例えば「開発」なら「API」「UI/画面」「バグ調査」など。最後に深さレベルを決める。

深さレベルの選び方:

• L1（名前だけ）: 最短投稿。「Claude Codeでバグ直した」程度
• L2（場所まで）: URL/...

Lovaiでは投稿にプレミアムコンテンツ（有料ロック）を設定できる。具体的な仕組み:

1. 無料部分: 投稿のinsight（結論）、成果物のスクリーンショット、工程ステップの概要（goalOneLine）は誰でも見える
2. 有料部分: 各テキストセクション（背景・やったこと・つまずき）と、核心ステップ（isCore）の詳細（プロンプト・設定・入出力）が有料ロック対象

価格設定の目安:

• ...

2024年、AIツールが爆発的に増えた。ChatGPT、Claude、Midjourney、Cursor...。でも「このツールでこんなことができた」という情報は、Xの断片的なツイートか、長大なブログ記事に散在している。再現しようとしても、バージョンが違う、設定が違う、そもそも前提条件が書かれていない。

AIの知識は今、3つの問題を抱えている:

1. 断片化: Xのツイート、ブログ、YouTub...

この3つの課題を同時に解決するプラットフォームとしてLovaiを設計した。

断片化の解決: 1つの投稿に「成果物 + プロセス + 思考」が全て入る構造化フォーマット。カテゴリ・ツール・難易度でフィルタリングでき、必要な知識にたどり着ける。

非再現性の解決: 工程ステップで「何のツールで→何を入力し→何を指示し→何が出力されたか」を記録。深さレベル（L1〜L4）で、名前だけの気軽な共有から完全...