3Dプリンターで印刷中に造形物が「ズレる」問題に悩まされている話

最近は3Dプリンター（Bambu Lab A1 Mini）にもハマっていて、自作パーツの設計にも挑戦中です。

今回、ペットボトルに取り付ける飲料水ポンプの変換アダプターを印刷しようとしたのですが……

😱 印刷中に、造形物がズレる！
プリント開始から数十分。順調に積層されていたはずの造形物が、途中からガクッとズレていました。
当然、完成品は使い物にならず。

最初は「たまたまかな」と思って再印刷。
でも、また同じ現象が起きました。

🔍 ブリムを試した → ダメ
まず「ブリム」を追加しました。
造形物の底面を広げてベッドへの接着面積を増やす方法です。

結果：ダメでした。ズレます。

🔍 ラフトを試した → たまにしか成功しない
次に「ラフト」を試しました。
造形物の下に格子状の土台を敷く方法で、ブリムより強力なはずです。

結果：成功するときもあるけど、失敗することも多い。安定しません。

🤔 原因が特定できない
ネットで調べると「ベッドの汚れ」「温度設定」「印刷速度」など、候補がたくさん出てきます。
でも、どれが自分のケースに当てはまるのか確信が持てない。

ソフトウェアのバグなら、ログを見ればだいたい原因が分かります。
でもハードウェアの問題は「再現性が不安定」で、原因の切り分けが難しい。
エンジニアとして、これが一番もどかしいところです。

💡 次の一手：スティックのり
次に試そうと思っているのが、ベッドにスティックのりを塗る方法です。
3Dプリンター界隈では定番の対策らしい。

正直「のりで解決するの？」という気持ちもあります。
でも、定番には定番になるだけの理由があるはず。

ソフトウェア開発でも「まさかそんな原始的な方法で？」という対処が正解だったことは何度もあります。

まだ解決していないので、続報があればまた書きます。
皆さんも3Dプリンターで「造形物がズレる」問題、経験したことありませんか？

==================================

当記事は、Claudeで校正校閲を実施したものになります。

2つのExcelファイルの差分を「目視」で比較するのはイヤなので、ツールを自作した話

Excelファイルを修正したとき、「どこが変わったのか」を確認したいことがあります。
テキストファイルならGitのdiffで一発ですが、Excelにはそれがない。😓

🔍 少量なら目視でやろうと思った
シートを2つ並べて、一行ずつ見比べる。
セルの数が少なければこれでもいけます。

でも、数百セルあるファイルで比較をやらなければいけなくなった瞬間、「これは人間がやる仕事じゃない」と確信しました。
見落としが怖い。そして何より、現在進行形で目が痛いのにさらに痛くなるでしょう。

🛠️ Pythonで差分比較ツールを作った
openpyxlというライブラリを使って、2つのxlsxファイルをセル単位で比較するスクリプトを書きました。

変更されたセルは黄色、追加は緑、削除は赤でハイライトしたExcelファイルを出力する仕組みです。

作ってみると、ロジック自体はシンプル。
「セルの値が違ったら色を塗る」、基本はそれだけです。

😲 「なぜ今まで作らなかったのか」という後悔
完成して使ってみた感想は、「もっと早く作ればよかった」の一言。

今まで目視で費やしていた30分が、一瞬で終わる。
しかもハイライトされるので、見落としがゼロ。

「面倒だけど手作業でもできること」って、つい後回しにしがちですよね。
でも、自動化したときのインパクトが一番大きいのは、まさにそういう作業だと実感しました。

皆さんも「面倒だけどまあいいか」で続けている作業、ありませんか？

==================================

当記事は、Claudeで校正校閲を実施したものになります。

メモリ4GBの古いMacでAIを動かしてみたら、まさかの「使えた」話

自宅に、メモリ4GBの古いMacがあります。
もう普段使いには厳しいスペックなので、Ubuntu Serverを入れてサーバーとして余生を送らせていました。

ある日ふと思いました。
「このマシンでAI、動かないかな？」🤔

💻 ダメ元で入れてみた
Ollamaというツールを使って、小型の日本語LLMモデル「gemma-2-2b-jpn-it」をインストール。
パラメータ数20億の軽量モデルです。

正直、4GBのマシンで動くわけないだろうと思っていました。

テストとして、クレジットカードの利用通知メールから「利用日時」「金額」「店名」を抽出させてみたところ……

😲 ちゃんと構造化データとして返ってきた！
驚きました。本当に動いたのです。

もちろん、GPTやClaudeのような大型モデルと比べれば精度は落ちます。
でも「メールから決まったパターンの情報を抜き出す」くらいの定型作業なら、十分に実用的でした。

💡 「AI＝ハイスペックマシン」とは限らない
AIというと、高性能GPU搭載の最新マシンを想像しがちです。
でも、「何をさせるか」を絞れば、古いPCでも立派に動く。

タスクの規模に対して、道具が過剰になっていないか？
そんな視点を持つきっかけになった体験でした。

皆さんも、自宅に眠っているPCがあったら、意外な使い道があるかもしれませんよ。

==================================

当記事は、Claudeで校正校閲を実施したものになります。

もはや「解読」ではなく「考古学」？他人のVBAコードを読むのに、開発の3倍時間がかかった話

副業でExcel VBAやGASを使った業務効率化ツールを作っていると、時々「既存ツールの解析」という依頼をいただきます。💻

先日も、「今動いているマクロを、もっと使いやすく作り直してほしい」というご相談がありました。

マクロ自体は、確かに動いています。
でも、その中身（VBAコード）を開いた瞬間、私は絶句しました。

😱 そこに広がっていた「カオス」な世界
コードを読み進めるうちに、作業は「開発」ではなく「遺跡の調査」のような状態に……。

• 謎の変数名: a, b, c……。何のデータが入っているのか、一行ずつ追わないと不明。
• 沈黙のコード: コメントが一切なく、書いた人の意図が見えない。
• 巨大な塊: 数百行にわたる処理が、一つのプロシージャに「べた書き」。
• コピペの嵐: 同じような処理が、あちこちに重複して散らばっている。

いわゆる「スパゲッティコード」の典型的な状態でした。

🕵️‍♂️ 「何をやっているか」はわかる、でも「なぜ」がわからない
プログラムなので、1行ずつ丁寧に追えば「何（What）」をしているかは分かります。
しかし、一番の難敵は「なぜ（Why）そうしたのか」が不明な点です。

特に頭を悩ませたのが、一見すると無意味に見える「謎の処理」。

「これ、消しても大丈夫かな？」
「いや、もしかして特定の環境だけで必要な回避策なのか……？」

そんな疑心暗鬼に陥り、判断を下すまでに膨大な時間を浪費してしまいました。

結局、全体のロジックを読み解き、全貌を把握するだけで、新しくゼロからコードを書く時間の「3倍」もの時間を費やすことになったのです。

💡 「動く」と「読める」の間にある、大きな壁
今回の件で、改めて痛感しました。
 

「動くコード」を書くのは当たり前。
「他人が読めるコード」を書くのが、本当のプロの仕事だ。

他人のコードを「読む側」に回ることで、自分の書くコードの「可読性」がいかに大切か、身に沁みて理解できた気がします。

皆さんも、未来の自分（あるいは誰か）に恨まれないような、優しさのあるコードを書いていますか？

私は……今回の苦い経験を糧に、より一層「美しいコード」を目指そうと思います。

==================================

当記事は、Geminiで校正校閲を実施したものになります。

3Dプリンターでアダプターを設計したら「非マニフォールド」に苦しめられた話

ペットボトルに取り付ける電動ポンプのアダプターを、3Dプリンターで自作しようとしました。

AIにOpenSCADのコードを書いてもらい、ネジ山やフランジの寸法を実測して設計。
4パーツに分割する構造も決まり、いざ3Dプリント用にレンダリング。

すると「非マニフォールド」という警告が出ました。

非マニフォールドとは、3Dモデルの面が数学的に破綻している状態のこと。
面同士がぴったり重なっていたり、厚みがゼロの箇所があると発生します。

原因を調べると、ネジ山と本体の面が一致していたり、三角形プロファイルの内接円計算がズレていたりと、目に見えない微妙な問題ばかり。

解決策を5パターン試して、ようやく全パーツの警告を消せました。
二重差分法、Z軸の微小延長、六角形プロファイルへの変更……どれも0.1mm単位の調整です。

コードの世界では1ピクセル単位の調整に苦労することがありますが、3Dの世界では0.1mm単位で苦労する。

「精度の壁」はどの分野でも同じなんだなと感じました。

==================================

当記事は、Claudで校正校閲を実施したものになります。

自宅IoT一元管理ツールを作りかけて中止した話

自宅にあるSwitchBot、EcoFlow、ワットチェッカーなど複数メーカーのデバイスを、1つのダッシュボードでまとめて監視したいと思い立ちました。

SwitchBotのAPI連携はうまくいきました。温湿度計やスマートプラグ4台のデータを5分間隔で取得して、Webで一覧表示するところまでは完成。

問題はその先でした。

ワットチェッカーにはそもそも公開APIがない。EcoFlowは開発者申請が必要で、一般ユーザーが気軽に使える仕組みではない。SwitchBotのBLEデバイスもHub Miniという別売りの機器がないとAPI経由で操作できない。

全部のデバイスが揃わないなら「全体を一元管理する」という目的自体が成り立ちません。

作り始める前に、全デバイスのAPI公開状況を調べるべきでした。1台でも連携できないものがあれば、ツールとしての価値が大きく下がる。

「動くところから作り始めて、あとは何とかなるだろう」という楽観が判断を遅らせた典型例でした💦

==================================

当記事は、Claudeで校正校閲を実施したものになります。

家計簿ツールの設計が完成した翌日に、前提が崩れた話

個人と事業の支出を1つのシートで管理するために、Zaim APIとfreee APIを連携させる家計簿ツールをGASで作っていました。

設計はこうでした。ZaimのAPIで銀行口座やクレカの明細を自動取得して、freeeの仕訳データと突合する。これで個人支出と事業経費を自動で仕分けできる、と。

Phase 1を実装し終えて、さあ次はZaimのAPI連携を仕上げよう、というタイミングで調べ直したところ、Zaim APIでは口座連携データが取得できないことが判明しました。

手入力のデータは取れる。でも、銀行口座やクレカから自動同期された明細は、APIの取得対象外だったんです。

家計簿アプリの価値の大部分は口座連携にあるのに、そこが取れないなら設計の前提が成り立たない。

結局、Zaim APIは廃止して、CSV取込方式に全面変更しました。マネーフォワードのCSVにも対応させて、さらにGmailのクレカ通知メールも取り込む設計に作り直し。

API仕様は「できそう」で進めず、「実際に取れるデータ」を確認してから設計すべきだった。ドキュメントに書いてあることと、実運用で使えることは別物だと痛感しました。

==================================

当記事は、Claudeで校正校閲を実施したものになります。

請求書テンプレートを「シート1枚に統合するだけ」が、修正8箇所になった話

VBAで作った請求書PDF作成ツールを改修しました。

やりたかったのはシンプルで、「入力シート」「設定シート」「請求書シート」の3枚構成を、請求書シート1枚に統合すること。
ユーザーが触るシートを1枚にまとめたほうが使いやすいだろうという判断です。

「シートをまとめるだけだから、すぐ終わるだろう」

ところが、シートを統合した途端に細かい問題が次々と出てきました。

品名欄のボーダーが崩れている。
金額欄のセル幅が足りない。
発行日の位置がズレている。
PDF出力時にラベル列が残って見えてしまう。
振込先のラベルが「振込先名」ではなく「振込先銀行」が正しい。
入力例シートも追加しないとユーザーが迷う。

結局、修正は8箇所以上に膨れました。

機能そのものは変わっていない。見た目とレイアウトの調整だけ。
でも「だけ」が一番厄介だったりします。

「簡単そうに見える改修ほど、実は修正箇所が多い」

これはシステム開発でもよくある話で、見積もりを甘くしがちなパターンです。
18年やっていても、毎回同じ罠にはまってしまいます。

==================================

当記事は、Claudeで校正校閲を実施したものになります。

AIに「このアイデア、売れる？」と採点させたら、自分の甘さが見えた話

ツール開発のアイデアを思いついたとき、「これは売れるだろう」と思い込んでしまうことがあります。

そこで、AIに企画を自動分析させる仕組みを作りました。
市場規模などの5項目を、各5点満点で採点させます。

最初は「市場規模」という1軸で点数をつけていたのですが、これだと判断が曖昧になる。
「なんとなく良さそう」で高得点がつきがちでした。

5軸に変えてからは、はっきり弱点が見えるようになりました。

たとえば、最初にテストしたアイデアは18点（25点満点）。
「市場規模は十分だけど、差別化が弱い」という評価でした。

AIが自動でリトライして、切り口を変えた企画を再提案。
2回目は22点でGO判定が出ました。

面白いのは、自分では「いいアイデアだ」と思っていたものが18点で、AIに練り直させたら22点になったこと。
自分の直感よりも、分解して数値化したほうが冷静に判断できるという当たり前のことを、改めて実感しました。

「これは売れる」という思い込みは、開発者にとって一番危ない判断ミスかもしれません。

==================================

当記事は、ChatGPTで校正校閲を実施したものになります。

全角スペース1つでAPIが壊れた話

自宅のIoTデバイス（温湿度計やスマートプラグ）のデータをサーバーに送って、外出先からダッシュボードで確認できる仕組みを作りました。

デバイスの名前付きでテストデータを送ろうとして、コマンドラインからJSONを送信したところ、サーバーから返ってきたのは「Invalid JSON」。

構文は正しいはずなのに。何度見直しても問題が見つからない。

原因はデバイス名に入っていた全角スペースでした。

半角スペースではなく全角スペース。
見た目ではまず気づけません。エディタでも普通のスペースにしか見えない。
でもコマンドラインを経由するとエンコーディングの扱いが変わり、JSONとして壊れてしまっていました。

結局、コマンドライン経由をやめてPythonスクリプトから直接送信したらあっさり成功。

全角スペースの罠は日本語環境だと定番のトラブルです。
知っていたはずなのに、やっぱりハマる。

「知識として知っている」ことと「実際に気づける」ことの間には、思ったより大きな溝があるなと感じた出来事でした。

==================================

当記事は、ChatGPTで校正校閲を実施したものになります。