masahiro
mke3idiot.bsky.social
masahiro
@mke3idiot.bsky.social
時間の錬金術師

人・データ・AIをつなぎ、時間を生み出す仕組みを考えています。
仕事では社内システム開発や業務改善。
プライベートではAI、自宅サーバー、IoT、自動化の実験。
生み出した時間を、人の成長や幸せにつなげることが目標です。
集計画面に「除外あり(推奨)/ 除外なし(全件)」という切替を付けたら、率直に指摘されました。「除外ありとなしの違いって何ですか?」

図星でした。私は「除外」という一つの言葉に、性質の違う3つの操作を混ぜていたのです。そして話すうちに、数え方が一意に決まるなら切替自体が要らないと分かりました。

https://mke3idiot.hateblo.jp/entry/2026/08/27/204050
October 10, 2026 at 12:06 AM
3千行を超える巨大なファイルを、機能ごとの小さなファイルへ切り分けました。中身は1文字も変えない純粋な移動のはずでした。

ところが、ある領域を移した直後にいくつかの画面が真っ白に。原因は「今いる場所を基準にして別のものを探す」という記述。置き場所が変わった時点で、基準がズレていました。移動そのものが挙動を変える一点でした。

https://mke3idiot.hateblo.jp/entry/2026/08/27/204049
October 9, 2026 at 1:32 AM
災害時に備えて、機密情報一式を暗号化して退避しました。整理して気づいたのは、鍵にも階層があるということ。

ほとんどの鍵はバックアップから復元できます。でも「そのバックアップ自体を開ける鍵」だけは例外でした。中に入れても暗号化されていて取り出せない。鶏と卵です。この1本だけは、別の手段で守る必要がありました。

https://mke3idiot.hateblo.jp/entry/2026/08/27/204048
October 8, 2026 at 2:06 AM
管理画面の自動撮影をしようとしたら、ページが真っ白で返ってきました。原因は、自分で作った入口の防御が、その自動化ツールを拒否リストに載せていたこと。

つまり防御は正しく機能していたわけです。ここで防御を緩めるのは筋が悪い。今回のアクセスは正当なものだったので、"自動化ツールの顔"ではなく"通常の利用者の顔"で名乗り直しました。

https://mke3idiot.hateblo.jp/entry/2026/08/27/204047
October 7, 2026 at 3:07 AM
優秀なAIが同じ日に3回連続で「この機能は無いので作りましょう」と提案し、3つとも既に本番稼働していました。

原因はAIの能力ではなく、150を超える部品に索引が無かったこと。「レベルの高いAIが間違えるほど、中がカオスということですよね」という一言が転機になり、概念地図という1枚の索引を作りました。

https://mke3idiot.hateblo.jp/entry/2026/08/27/204046
October 6, 2026 at 1:48 AM
古くなった操作マニュアルを作り直す、というだけの依頼でした。

ところが「この操作をすると、こう動く」を書くために現物と1機能ずつ突き合わせたところ、説明と実装のズレが次々に出てきました。「必ず届きます」と書いた機能が実は条件付きだった箇所が3つ。そして、大事なデータが無警告で上書きされる本物のバグが1個。

https://mke3idiot.hateblo.jp/entry/2026/08/27/204045
October 5, 2026 at 12:17 AM
動画の提出が「数値が範囲外」というエラーで弾かれる。原因は、ファイルサイズを収める器が約21億までしか入らない型だったこと。境界を1バイトでも超えた瞬間に落ちる、静かな上限地雷でした。

厄介だったのは、開発用の土台が「勝手に器を広げてくれる」寛容なタイプで、手元では絶対に再現しなかったこと。同じコードでも、土台が違えば振る舞いは同じとは限りません。

https://mke3idiot.hateblo.jp/entry/2026/08/27/204044
October 4, 2026 at 2:12 AM
全拠点ぶんの外部連携キーを登録する作業。AIには「認証情報の値を読む・入力する」ことを禁じるガードがあり、ここは越えられません。

そこで発想を変えました。値を触るのは本人のパソコンだけ、AIはその作業を全自動化する道具を書くだけ、という分業です。結果、数十回のコピペが「ログイン1回+貼り付け1回」になり、AIは秘密の値を一度も見ていません。

https://mke3idiot.hateblo.jp/entry/2026/08/27/204043
October 3, 2026 at 1:31 AM
「同じ言葉の指標なのに、画面によって数字が違う」。数字を出している画面・端末表示を50箇所超すべてリストにし、それぞれのデータ源を発生源まで遡りました。

結果、同じ指標が2〜5通りに再実装されているグループが8つ。二重管理の本当のコストは保守の手間ではなく「片方だけ直る」ことだと分かりました。

https://mke3idiot.hateblo.jp/entry/2026/08/27/204042
October 2, 2026 at 1:00 AM
現場から「予約ページのオプション選択ボタンが分かりにくい」と要望が1件。とりあえず大きくする対応ではなく、人間工学・UX・UI・企業理念という4つの視点で同じ画面をレビューしました。

面白いのは、指摘が綺麗に役割分担されたこと。押しやすさ、言葉づかい、押せそうに見えるか、そして文言のトーン。1つの視点で直していたら、確実に取りこぼしていました。

https://mke3idiot.hateblo.jp/entry/2026/08/27/204041
October 1, 2026 at 2:14 AM
「動画が読み込み中のまま始まらない」という報告を調べ、サーバー側は全部シロだと確認しました。代わりに別の不具合を見つけ、これが原因だと結論しかけたのです。

そこへ利用者から「一度違うアプリを開くと再生される」という一言。これが決定的でした。利用者が見つけた"なぜか動く回避策"が、そのまま原因の証明になっていたのです。

https://mke3idiot.hateblo.jp/entry/2026/08/27/204040
September 30, 2026 at 1:43 AM
「2通目のお知らせだけ必ず届かない」という不具合を、丸一日誤診し続けました。エラーの表面だけを見て、原因を3回取り違えたのです。

救ってくれたのは「その場しのぎではなく、やりたいことに対してやり方自体が合っているか確認して」という依頼主の一言。目的まで巻き戻って公式の説明を読み直したら、見落としていたのは1行だけでした。

https://mke3idiot.hateblo.jp/entry/2026/08/27/204039_1
September 29, 2026 at 12:43 AM
指標設計を、経営者の「目的と軸」とAIの「実データ検証」の分業でやってみました。

面白かったのは、検証のたびに設計が具体的に良くなったこと。「そろそろ来なくなりそうなお客様に声をかける」という素朴な案を過去2年分の履歴で検証したら、月次の気づきでは手遅れだと数字が先に教えてくれました。アイデアの正しさは、議論ではなくデータで即日確認できます。

https://mke3idiot.hateblo.jp/entry/2026/08/27/204039
September 28, 2026 at 12:57 AM
「この予約サービス、いつのまにか集客全体を担う存在に膨らんでいる気がする」。そう不安になって点検したら、実はズレていませんでした。

相談のたびに線引きは働いていて、はみ出す分は「将来の別プロジェクト」に振り分けられていた。ただ、その別プロジェクトがまだ存在しないので、行き先のないアイデアが全部"玄関先"に積み上がって見えていただけだったのです。

https://mke3idiot.hateblo.jp/entry/2026/08/27/204038
September 27, 2026 at 12:44 AM
同じ直しを複数のファイルへ一括適用しました。処理は全部「適用しました」と表示し、確認も全部通った。なのに翌朝、夜間処理が止まりました。

1本だけ、対象の文字列が微妙に一致せず"半端に"書き換わっていたのです。しかも半端でも形式としては正しいので、機械的な確認はすり抜ける。「当てたか」ではなく「当たったか」を確かめないと意味がない、という話です。

https://mke3idiot.hateblo.jp/entry/2026/08/27/204037
September 26, 2026 at 3:45 AM
データ基盤を新しいものに移した後、現場から「通知の設定が"通信エラー"で登録できない」と連絡が来ました。

原因は、旧と新で「値が空でも安全に一致を判定する書き方」が微妙に違っていたこと。しかも特定の入力が入ったときだけ発火するので、ざっと動かす確認をすり抜けていました。移行の地雷は、派手なデータ構造ではなく小さな言い回しの差に潜んでいます。

https://mke3idiot.hateblo.jp/entry/2026/08/27/204036
September 25, 2026 at 2:17 AM
「審査画面では合格が出ているのに、本人の記録には合格が無い」。現場の違和感1件から調べたら、5ヶ月分・100件超の記録が一度も書き込まれていませんでした。

怖かったのは、壊れ方が"半分"だったことです。すでに記録がある人は「更新」の経路を通るので成功し、失敗するのは「その項目を初めて受けた人」だけ。日常操作の大半は更新なので、誰にも見えないまま5ヶ月が過ぎました。

https://mke3idiot.hateblo.jp/entry/2026/08/27/204035
September 24, 2026 at 1:31 AM
AI・コンサル・部下から「改善提案リスト」を受け取る。件数が多いほど「やることが山積み」と焦りますよね。

でも決裁者の本当の仕事は、上から順に潰すことではありません。「すでに解決済み」「一過性」「同じ話の水増し」を見抜いて、限られた人手と時間をどこに割くかを決めることです。

リストの真贋を、印象でなく事実で選り分ける話です。

https://mke3idiot.hateblo.jp/entry/2026/07/30/163453
September 23, 2026 at 1:34 AM
「連絡は来たのに手続きできない」。予約・契約・入社…あらゆる現場で起きる、片方の記録だけが静かに欠ける事故。

エラーが出ないから誰も気付けません。この"サイレントな片手落ち"を未然に防ぐための確認項目を、チェックリスト形式でまとめました。

https://mke3idiot.hateblo.jp/entry/2026/07/30/163451
September 22, 2026 at 1:39 AM
「エラーも出ていない、苦情も来ていない。だから問題なし」。

経営者としてそう判断していた裏で、見えないコストが毎日静かに漏れていました。

痛みが出ない損失を、勘ではなく仕組みで定期点検する話です。

https://mke3idiot.hateblo.jp/entry/2026/07/30/163450
September 21, 2026 at 2:09 AM
「届いてます」「共有しました」と言われるのに、自分の手元では使えない。

「こちらの環境の問題かも」と黙り込むと、相手は完了したつもりのまま。

使う側が"事実+再現手順"で伝え方を変えたら動いてもらえた、という話を書きました。

https://mke3idiot.hateblo.jp/entry/2026/07/30/163448
September 20, 2026 at 2:08 AM
「もっとデータを取れば経営判断できる」と新しいシステムに投資する前に、社内にある2種類のデータを掛け合わせてみてください。

申告営業時間 × 実取引時刻を突き合わせるだけで、「隠れた残業」が拠点別に数字で出ました。新規投資ゼロ、集めた新データは1バイトもありません。

https://mke3idiot.hateblo.jp/entry/2026/07/30/163447
September 19, 2026 at 12:26 AM
「売上が伸びた」「利益率が改善した」— 経営会議で毎回飛び交う言葉。

でもその"売上"が、去年と今年で"同じ作られ方"をしているとは限りません。列名が同じでも、途中で計算方法が変わっていることがある。

他社と、過去と、部門と比べる前に。決裁者がやるべき「この数字はどう作られたか」の確認について書きました。

https://mke3idiot.hateblo.jp/entry/2026/07/30/163446
September 18, 2026 at 12:30 AM
「あの人の権限、もう切ったよね?」がふわっとしている組織は、たぶん一時的な権限を"切ったつもり"で放置しています。

代理・期間限定・退職者の権限を、用途ごとに有効期間で区切り、"入れる範囲"と"見える範囲"を分けて統制する話です。

https://mke3idiot.hateblo.jp/entry/2026/07/30/163444
September 17, 2026 at 12:41 AM
外部サービス(決済・地図・動画…)に頼るツールは必ずたまに落ちます。問題は落ちた瞬間の作り。

「エラーは出ているのに危険な操作は素通り」「失敗したら入力が全部消える」——使う人が本当に困るのはここ。

使う側の体験と、良いツールの見分け方の話です。

https://mke3idiot.hateblo.jp/entry/2026/07/30/163442
September 16, 2026 at 1:08 AM