問いを、書きながら育てる。

連載「carb-icr 開発日誌」· 第14編

自動化は、手入力を奪ってはいけない

仕組みが届かない時間を、設計に織り込む（開発日誌 14）

センサーが値を返さない時間が、現実にはどうしても生まれます。そのとき手で入れられないと、道具は止まってしまう。自動化が、人の手を奪わない。現実の空白を前提に置く。最後まで守ったその一線の話を、一緒に。

連載「carb-icr 開発日誌」· 第13編

足すより、削る

作れることと、作るべきことは、違った（開発日誌 13）

写真から食事を解析できると分かると、つい「ついでにあれもこれも」と欲が出ます。でも、目的に要らない機能は作らない。最小で出して、欲しくなったら足す。足すより削るほうが難しくて、よく効いた話を、一緒に。

連載「carb-icr 開発日誌」· 第12編

「動く」と「ちゃんと出る」は、別だった

自分の目で見るまで、確かめたことにはならない（開発日誌 12）

コードがエラーなく動く。それで「できた」と思いがちです。でも実際に出てきた画面を見るまで、ちゃんと出ているかは分かりません。理屈ではなく目で確かめる、その当たり前を取り戻した話を、一緒に。

連載「carb-icr 開発日誌」· 第11編

人が知っていることを、AIに渡す

推測させる前に、確かな手がかりを1つ添える（開発日誌 11）

写真だけでは、AIはどの料理か、どれだけの量かを推測するしかありません。でも、それを注文した私は知っている。知っていることを一言添えるだけで、見積もりは見違えました。推測させる前に確かな手がかりを渡す、その小さなこつを一緒に。

連載「carb-icr 開発日誌」· 第10編

知識には締め切りがある。でも、今を取りに行ける

新メニューを前に、AIが値を当てられなかった話（開発日誌 10）

新メニューの糖質を、AIがだいぶ低く見積もってきました。正解と並べて初めて気づいた誤差。原因は、その料理がAIの知識の締め切りより後に出たこと。知らないなら、今を取りに行かせればいい。その解き方を、一緒に。

連載「carb-icr 開発日誌」· 第9編

AIの知識は、古いことがある

動かないとき、疑うのは自分のコードだけではない（開発日誌 9）

AIに書いてもらったコードが動かない。原因は私の書き間違いではなく、AIが前提にしていた値が古かったことでした。変わりやすい事実は、AIの記憶ではなく、いまの一次情報で確かめる。その習慣の話を、一緒に。

連載「carb-icr 開発日誌」· 第8編

「漏れはなさそう?」が、点検を始めさせる

問いひとつで、AIが自分のコードを疑い始めた（開発日誌 8）

動くコードが揃ったとき、軽くかけた「漏れはなさそう?」の一言。それだけでAIが自分の書いたものを疑い直し、本番で表に出るはずだった不具合を、机の上で未然に見つけました。問いがそのまま点検の工程になる話を、一緒に考えます。

連載「carb-icr 開発日誌」· 第7編

制約を明かすたび、設計が組み変わる

AIが知らない「私の事情」が、設計を動かしていた（開発日誌 7）

同じ相談でも、自分の事情を1つ伝えるたびに、AIの出す設計はそのつど引き直されました。手元の道具、すでにやったこと、契約しているもの。AIが知り得ない私の現場情報こそが、設計を動かしていた話を、一緒に。

連載「carb-icr 開発日誌」· 第6編

ボトルネックは、思っていた場所になかった

自動化したい本丸が、途中で入れ替わった（開発日誌 6）

糖質の入力をなくしたくて始めた自動化が、途中から血糖の話に入れ替わりました。一番面倒だと思っていた場所と、本当の難所は別だった。調べて初めて中心がずれた、その仕組みを一緒に。

連載「carb-icr 開発日誌」· 第5編

どこから出てくるか、を先に調べる

自動化の8割は、データの出口調べでした（開発日誌 5）

何を自動化するかが決まっても、すぐにAIには飛びつきませんでした。先にやったのは、欲しいデータがどこから、どんな形で、いつ出てくるかを1つずつ確かめること。その地味な出口調べが設計の大半だった話を、一緒に。

連載「carb-icr 開発日誌」· 第4編

道具の名前で聞くと、答えは小さくなる

AIへの問いの立て方で、設計は動く（開発日誌 4）

新しいAIに「これで何ができる?」と聞くほど、答えはその道具の大きさに縮みます。問いの向きを、道具から課題へ変えたとき、設計が動き出した——その仕組みと、明日から使える問いの立て方を、一緒に。

連載「carb-icr 開発日誌」· 第3編

公開しないで、自分のために持つ

自作自用という、もうひとつの道（開発日誌 3）

自分の体のために作った道具を、あえて誰にも渡さない。公開して鍵をかける案がなぜ成り立たないのか、そして「ネットワークごと閉じる」という解き方を——便利さを手放さずに提供はしない設計を、一緒に。

連載「carb-icr 開発日誌」· 第2編

判断は医師に、道具は資料に

公開版から投与量計算を外し、役割を作り直す（開発日誌 2）

便利な機能を消したら、その道具に何が残るのか。投与量計算をまるごと外し、残った数字を「逆算」から「主治医に見せる記録の集計」へ——役割そのものを作り直した手の動かし方を、一緒に。

連載「carb-icr 開発日誌」· 第1編

手計算の代行が、医療機器になるとき

個人開発と薬機法のはざまで（開発日誌 1）

個人で作った便利な道具を、そのまま人に配っていいのか。無償・免責・デフォルトOFF——「対策したつもり」がほとんど効いていなかった話と、情報を渡すことと道具を渡すことを分ける一本の線を、一緒に。

連載「carb-icr 規制日誌」· 第4編

根拠は、買って確かめる

孫引きをやめて、原典を開く（提出編 4）

「これの根拠は?」と聞かれて、ネットの孫引きで済ませていませんか。出典を本で買って該当ページを開いたら、もっと適切な出どころが見つかりました。根拠を現物で確かめる地味な一手の話を、一緒に。

連載「carb-icr 規制日誌」· 第3編

「危ないかも」を、事例に重ねる

不安をぶつけず、当てはめを差し出す（提出編 3）

自分のアプリが医療機器かもしれない。その不安のまま手が止まっていませんか。怖さは、公開されている事例に重ねると輪郭になりました。問いの向きを不安から当てはめへ変える話を、一緒に。

連載「carb-icr 規制日誌」· 第2編

ひとつの道具を、機能で分けて見る

まるごと1つで身構えない（提出編 2）

申請の様式に「機能名」とあると、アプリ全体をまとめて1つと書きたくなります。でも機能ごとに分けてみたら、本当に説明が要るのは1つだけでした。塊を割って身構えを解く話を、一緒に。

連載「carb-icr 規制日誌」· 第1編

「これ、医療機器ですか」を、どこに聞くか

相談する前に、相談先を間違えない（提出編 1）

個人で作った健康アプリを「医療機器に当たらないか」相談したい。でも、どこに聞けばいいか分かりますか。窓口は1つではありませんでした。目的に合う入口の選び方を、一緒に。

連載「糖質/インスリン比 目安アプリをつくる」· 第7編

数字を、共通言語に

なぜ私はこれを作っているのか（その7・最終回）

一日中、小さな判断を一人の頭で続ける孤独。その「なんとなく」を数字とグラフに翻訳し、患者と医師の共通言語にする——シリーズの底にあった願いを、最終回として一緒に。

連載「糖質/インスリン比 目安アプリをつくる」· 第6編

無料のまま、どう続けるか

ライセンス・ソース公開・支援の設計（その6）

良いものを作っても、続けられずに消えてしまう。「無料」を値段ゼロで終わらせないために——コスト・ライセンス・支援・ドメインで「続く形」に落とし込んだ設計を一緒に。

連載「糖質/インスリン比 目安アプリをつくる」· 第5編

あえて、機能を引っ込める

インスリンに触れる道具と、規制への向き合い方（その5）

作れるのに、あえて出さない。インスリンの量に触れる道具をどこで止めるか——同意・注意・既定オフという引き算の設計と、「制約が信頼になる」という気づきを一緒に。

連載「糖質/インスリン比 目安アプリをつくる」· 第4編

点を打つと、傾きが答えになる

グラフを部品なしで自作した話（その4）

数字の表をいくら眺めても傾向は見えない。点を打って線を引くと、その傾きがそのまま答えになる——記録を「発見の道具」に変えるグラフを、部品を使わず自作した話を一緒に。

連載「糖質/インスリン比 目安アプリをつくる」· 第3編

治療は、固定じゃない

「方式が変わる」をデータ構造に織り込む（その3）

いまの状況に合わせて作った道具が、状況が変わった途端に使えなくなる——その脆さを避けるために、「治療方式は変わる」を最初からデータ構造へ。長くつきあう道具の設計を一緒に。

連載「糖質/インスリン比 目安アプリをつくる」· 第2編

「正確な数字」より「いまの数字」

生活の揺らぎを、設計でどう受け止めるか（その2）

理屈どおりに組んだ仕組みが、暮らしに「そうじゃない」と突き返される。基礎インスリンは毎日同じじゃない——その揺らぎを、賢い計算ではなく素直な受け取り方で解いた話を一緒に。

連載「糖質/インスリン比 目安アプリをつくる」· 第1編

「糖質を引き算するだけ」のはずだった

1型糖尿病の自分のために、血糖管理アプリをAIと作る（その1）

炭水化物から食物繊維を引くだけ——のはずが、毎日くり返すと消耗する。小さな手間を機械に預ける、その一歩を、1型糖尿病の自分のためにAIと作りはじめた話から一緒に。

連載「AIに任せきりにしない発信をつくる」· 第21編

止まらないより、止まっても起き上がれるように

自動化を、こける前提で組む

自動で動く仕組みは、いつかどこかでつまずきます。だから私たちは、止まらないことより、止まっても自分で拾い直せることを目指しました。地味だけれど効く、運用の設計の話を一緒に。

連載「AIに任せきりにしない発信をつくる」· 第20編

その「バズる法則」、出どころはどこですか

もっともらしい数字ほど、確かめてみる

SNSでよく見る「◯分で◯返信」「ハッシュタグは控えめに」。確かめてみたら、その多くは出どころのあいまいな言い伝えでした。もっともらしい数字を、一次情報に当ててみた話を一緒に。

連載「AIに任せきりにしない発信をつくる」· 第19編

AIが、良いものまで捨てたとき

直したのは、モデルではなく問いでした

AIに「これは価値があるか」と尋ねたら、良いものまで捨ててしまいました。直したのはモデルでも例でもなく、問いの立て方。問いを変えると答えが変わる、を一緒に。

連載「AIに任せきりにしない発信をつくる」· 第18編

投稿しても届かないなら、会話から

AIに任せきりにしない、半自動のリプライ

投稿を磨いても、見てくれる人がいなければ届きません。では、最初の読者はどこから来るのでしょう。待つのをやめて、こちらから会話を始めてみた話を、一緒に。

連載「AIに任せきりにしない発信をつくる」· 第17編

「伸びない」と「届いていない」は、ちがう

感想を数字にすると、次にやることが変わる

発信が「伸びない」と感じても、それはまだ感想かもしれません。表示回数を測ってみたら、見えてきたのは「届いていない」という別の問題でした。測ってから考える、を一緒に。

連載「AIに任せきりにしない発信をつくる」· 第16編

自動化ツールに、なぜキャラクターを持たせるのか

「誰が話しているか」を設計することの意味

発信を自動化するツールを作っていると、「全部AIに任せればいいのでは」と聞かれます。任せられます。でも AZASLAB はそうしませんでした。AIが作り、人が確かめ、アズラビが届ける——その3層を設計した理由を、一緒に考えてみます。

連載「AIに任せきりにしない発信をつくる」· 第15編

信じていた台帳が、古かった

同じことを2か所に書くと、いつか食いちがう

正しく指示したはずなのに、なぜか順番が狂う。原因は、しくみが見ていた台帳の日付が、原本とずれていたことでした。「どれが本物か」を決めておく——その大切さを、自社発信づくりのふりかえりから一緒に。

連載「AIに任せきりにしない発信をつくる」· 第14編

作ったのに、たどり着けない

危うく、告知に「帰り道」を付け忘れるところだった話

これから自動で出していく告知の下書きから、肝心の「続きはこちら」のリンクが抜けていた。あとで付けるはずのしくみが、作られていなかったのです。出す前に気づけた実装漏れの話を、自社SNS自動化づくりから一緒に。

連載「AIに任せきりにしない発信をつくる」· 第13編

テストのつもりが、本番を進めていた

「何もしない」が、徹底できていなかった話

本番前の「空打ち」は安全なはずでした。でも、出さないだけで内部の記録は進んでいて、後から「もう済んだこと」になっていた。安全モードの落とし穴を、自社SNS自動化づくりのふりかえりから一緒に。

連載「AIに任せきりにしない発信をつくる」· 第12編

もし止まって、また動き出したら

予約配信を本番にする前に、考えておいたこと

予約投稿を自動で出すしくみ。本番にする前に、ふと気になりました——もし途中で止まって再開したら、溜まったぶんはどうなる？ 確かめたら、一斉に飛ぶ作りでした。溢れさせる前に手を打った話を、自社SNS自動化づくりから一緒に。

連載「AIに任せきりにしない発信をつくる」· 第11編

「何を書くか」と同じくらい、「いつ出すか」

承認したら即投稿、をやめて予約制にした話

良い内容でも、出すタイミングで読まれ方は変わります。「承認＝即投稿」をやめ、朝・昼・夜の枠に予約する仕組みにしました。発信のタイミングを仕組みで設計する——その考え方を、自社SNS自動化づくりから一緒に（効果の検証はこれから）。

連載「AIに任せきりにしない発信をつくる」· 第10編

小さく出して、確かめてから広げる

本番の前に「空打ち」で全部を通してみる

いきなり本番で大量に出すのは、こわい。だからまず「空打ち」で全経路を通し、配信も少量から始めました。出す前に確かめる、一気に広げない——取り返しのつかない操作と付き合うコツを、開発の実践から一緒に。

連載「AIに任せきりにしない発信をつくる」· 第9編

「誰に向けて書くか」を、1文で言えますか

刺さらない原因は、口調ではなく“あいまいな読者像”でした

直しても直しても響かない文章。原因は、対象読者がぼんやりしていたことでした。読者像を一文で具体化したら、選ぶネタも書き方も変わった。ターゲットの解像度の話を、自社発信づくりのふりかえりから一緒に。

連載「AIに任せきりにしない発信をつくる」· 第8編

AIに任せきりにしない、を“発信そのもの”でも

全自動にできるのに、最後の一押しを人間に残した理由

投稿を全自動にすることもできました。でも、世に出す最後の判断だけは人間が握る「半自律」にしました。自動化すべきは手間であって、判断ではない——その線引きを、自社SNS自動化づくりから一緒に考えます。

連載「AIに任せきりにしない発信をつくる」· 第7編

賢い自動判定が、“自分の場合”で静かに外すとき

日本語の記事を「ナビゲーション」と誤判定したAI

汎用の賢いルールやAIは、たいてい多数派に最適化されています。だから自分の文脈ではこっそり外れることがある。日本語記事が捨てられていた小さな事件から、「一般に正しい」と「自分に正しい」の違いを一緒に考えます。

連載「AIに任せきりにしない発信をつくる」· 第6編

「前は動いていたのに」を、ひとつずつ疑ってみました

コード？マシン？回線？——犯人を切り分けるまで

「別のPCでは動いていたのに、ここでは動かない」。原因はコードでも機種でもなく、相手側の仕様変更でした。「同じはずなのに」を1つずつ切り分ける——その問い直しの過程を、ある開発のつまずきから一緒に。

連載「AIに任せきりにしない発信をつくる」· 第5編

トーンは、口調だけじゃない — まだ仮説ですが

「丁寧にした」のに響かなくなった理由を考えてみます

同じ内容・同じ丁寧さなのに、なぜか響かない文章があります。文章の“温度”は口調ではなく、誰をどう巻き込むかの構造にある——という仮説を、自社発信づくりの失敗から立ててみます。検証はこれから。

連載「AIに任せきりにしない発信をつくる」· 第4編

「無料でできるはず」が、もう古かった話

つくっている途中で、前提のほうが入れ替わっていました

無料でできるはず、と思って進めたら、その前提自体が数か月前に消えていた。AI時代は「半年前の常識」が驚く速さで古くなります。前提を確かめることの大切さを、ある開発のつまずきから一緒に。

連載「AIに任せきりにしない発信をつくる」· 第3編

AIが書いた“もっともらしい話”を、そのまま流さないために

自分の発信にこそ、事実確認のひと手間を

ネットやAIから拾った“それっぽい話”は、そのまま信じると少し危ういものです。発信する側こそ、裏付けを確かめたい。自社SNS自動化に事実確認のゲートを入れた理由を、一緒に考えます。

連載「AIに任せきりにしない発信をつくる」· 第2編

「言いたいこと」から書くのを、やめてみました

知恵袋で悩みを探した時代と、AIにRedditの困りごとを探させる今

発信が読まれないのは、内容が悪いからとは限りません。「自分が言いたいこと」ではなく「誰かの困りごと」から始める——古くて新しいコンテンツ術を、自社SNS自動化づくりのふりかえりから、一緒に考えます。

連載「クリシンクエストをつくる」· 第8編

「つくる」から「世に出す」へ — ベータ公開の地ならし（最終回）

動いて、速くて、安全で、見た目も整った。それでも公開ボタンの前に、もうひと仕事あった

連載最終回。動くものを「世に出す」前には、もうひと仕事があります。データを預かる約束を明文化する法務ページ、あえて入口を絞るベータ、最後の細部の詰め。そして「完璧を待たずに出す」という判断。AIエージェントと組んで開発してきたクリシンクエストを、どう世に送り出したかをお話しします。

連載「クリシンクエストをつくる」· 第7編

AIを相棒に、コードを書かずに開発する — ディレクターの実際

ここまでの設計も移行も認証もデザインも、私はほとんどコードを書いていない。では、何をしていたのか

この連載で語ってきた設計・移行・速度改善・認証・デザイン。その全部を、私はコードをほとんど書かずに、AIエージェントたちと進めてきました。「AIエージェント開発ディレクター」が実際に何をしているのか。任せること、決めること、問い直すこと。AIを「答えを出す道具」ではなく「問いを深める相棒」として開発する働き方を、お話しします。

連載「AIに任せきりにしない発信をつくる」· 第1編

AIは、自分で描いた地図を見なくなる — ある開発のふりかえり

「流用するだけ」と決めたはずが、なぜ一から作り始めたのか

AIに「すでにあるものを使って」と頼んだのに、よく似たものを一から作り始めた。しかもAIは、正しいやり方を最初に自分で言っていました。AIと組む面白さと難しさを、ある開発のふりかえりから、一緒に考えます。

連載「クリシンクエストをつくる」· 第6編

「ダサい」を、レイアウトから直す — 伝わる見た目への作り直し

中身が良くても、見た目で伝わらなければ届かない。1カラム化と引き算で整え直した話

中身がどれだけ良くても、見た目で伝わらなければ届きません。世に出す前に、クリシンクエストの見た目をレイアウトから作り直しました。1カラム化、重複の削除、相手に合わせた入口、細部の詰め。デザインを「飾り」ではなく「翻訳」として捉え直した記録です。

連載「クリシンクエストをつくる」· 第5編

ログインは、つくらない・混ぜない — 入口を3つに分けた話

パスワードは自分で抱えない。身分証はJSから触れない場所に。そして立場ごとに入口を分ける

ログインは地味ですが、いちばん事故が怖いところでもあります。クリシンクエストは自前の認証をやめて専門サービスに預け、トークンの持ち方を工夫し、さらに学習者・企業担当者・運営者で入口（URL）を分けました。なぜ「つくらない・混ぜない」が安全につながるのかを、開発の裏側からやさしくお話しします。

連載「クリシンクエストをつくる」· 第4編

8秒が0.3秒になった、たった1行の設定 — 速さの正体は「距離」だった

同じコード、同じデータベース。なのに本番だけ激遅。犯人は地球の裏側にいました

本番に出したクリシンクエストが、なぜか異常に遅い。同じコード・同じデータベースなのに表示に8秒以上。原因を追うと、アプリとデータベースが太平洋をはさんで離れていました——速さの正体は「距離」だったという、たった1行で30倍速くなったお話です。

連載「クリシンクエストをつくる」· 第3編

「動く」から「届く」へ — 個人開発で本番環境をつくった話

手作りのサーバーから Vercel + Supabase へ。土台は入れ替えても、コードの“呼び方”は変えませんでした

自分のPCで動くのと、誰でも使えるのは別物です。クリシンクエストを手作りのサーバーから Vercel と Supabase へ引っ越した記録。サーバーレスの制約、データベースの方言、同期から非同期への書き換え——移行を支えた“互換アダプタ”という考え方を、開発の裏側からやさしくお話しします。

連載「クリシンクエストをつくる」· 第2編

正解を、ブラウザに渡さない — 見抜くゲームを成立させる設計

“ソースを見れば答えがわかる”をどう防いだか。秘密は「隠す」のではなく「渡さない」ことでした

見抜くゲームは、答えがどこかに置いてあれば成立しません。ブラウザは中身がすべて見えてしまう——だからクリシンクエストは「正解をクライアントに渡さない」設計にしました。サーバー権威という考え方を、開発の裏側からやさしくお話しします。

連載「クリシンクエストをつくる」· 第1編

AIに「本当っぽい嘘」を語らせる — クリシンクエストの心臓部

嘘をつくらせる技術ではなく、嘘を“ちょうどよく”保つ制御のお話です

AI時代の批判的思考ゲーム「クリシンクエスト」では、3体のAIのうち1体に“本当っぽい嘘”を語らせます。完全なデタラメでも全部正直でもいけない——その絶妙なさじ加減をどう設計したのかを、開発の裏側からやさしくお話しします。

連載「「あれ？」が、あなたを賢くする」· 第3編

ふり返りと、成長 — 問いが変わる

経験を学びに変える最後のひと手間「ふり返り」。そして成長とは、答えが増えることではなく、立てられる問いが変わっていくこと。一緒に確かめていきます。

連載「「あれ？」が、あなたを賢くする」· 第2編

脳のしくみと、「知りたい」という力

「あれ？」のとき、脳の中では何が起きているのでしょう。予想する機械としての脳と、私たちが進んで「知りたい」と思ってしまう好奇心のしくみを、やさしく見ていきます。

連載「「あれ？」が、あなたを賢くする」· 第1編

学びの正体 — 頭の中の「地図」と「あれ？」

学びとは知識が増えることではなく、頭の中の「地図」が描き直されること。小さな違和感「あれ？」から学びが始まるしくみを、ゼロから一緒に見ていきます。