光都ICTクラブ（2026年10月）～先人の知恵を学べ～

2026年10月4日 2026年10月4日 nakahara_takahiro

金曜日は、毎週（第五金曜のぞく）光都ICTクラブの定例会が開催中です。メンバーみんなが、それぞれ課題を持ち寄って取り組んでいます。

タイマーが出来たので表面実装

前回から始めたタイマーの制作が、あっという間に完成しました。

8x8x8CubeLEDに比べれば、タイマーは赤子の手をひねるようなものです。512個のLEDを並べてはんだ付けしてきたメンバーにとって、タイマー程度の部品点数ではもう手が止まりません。大きなものに取り組んで腕を鍛えておけば、次のものは驚くほど簡単にできてしまう。そのいい例だと思います。最後に少しだけ手直しが入りましたが、写真のとおり、タイマーはきっちり動きました。

続けて、今度は少し骨の折れるものに取り組みます。表面実装の練習です。

これまで作ってきたものは、部品のリード線（足）を基板の穴に差し込み、裏からはんだ付けするタイプでした。表面実装は、穴を使わずに基板の表面へ直接部品をはんだ付けする方法です。今の電子機器の多くはこの方式で作られていますが、手作業でやると難易度は格段に上がります。

まずは回路図を見ながら、どこに何をはんだ付けするのかを確認しました。そのうえで、チップ抵抗、続いてチップコンデンサーの順に進めます。一度に全部をはんだ付けするのではなく、部品の種類ごとに一区切りつけ、ひとつずつ説明しながら進めました。

何より対象が小さい。ピンセットで部品をつまみ、位置を合わせたままはんだ付けする、というのがかなり難しいところです。

はんだの量も、これまでとは比べものにならないほど少なくなります。多すぎるとすぐに団子になり、部品が浮いたり、はんだ不良になったりします。基板表面のパターン（配線）も小さく狭いので、はんだが多ければすぐに隣とつながってブリッジしてしまいます。リード部品なら許されていた「少し多め」が、表面実装では通用しません。

ここまでできるようになると、はんだ付けの腕はかなり上がります。CubeLEDで鍛えた腕がタイマーを簡単にしたように、表面実装で鍛えた指先は、この先どんな電子工作に取り組むときにも効いてくるはずです。

次回も引き続き、表面実装の練習を進めていきます。

3x3x3CubeLED、裏面配線がまだまだ続く

3x3x3CubeLEDのチームは、今回も裏面の配線が続きました。おそらく、この制作でいちばん根気のいる作業です。

初めての電子工作で、ユニバーサル基板（穴だけが並んだ汎用の基板）に手はんだで回路を組んでいくのは、かなり難しいと思います。まだ回路図を読める段階ではないので、実物を目で追いながら、一か所ずつはんだ付けを進めています。

もうひとつの壁が工具、特にラジオペンチの扱いです。使い慣れていないので、リード線やスズメッキ銅線をまっすぐ曲げるだけでも一苦労しています。すぐにフニャフニャになってしまうのはご愛嬌です。誰でも最初はそうで、失敗を繰り返すうちに、自分なりにきれいに仕上げる方法を見つけていくものです。

要所要所では、私がサポートに入ったり、お手本を見せたりしています。ただ、大事なのはそこから先です。手元を見て何を感じ、何を学び取るか。そこは本人にしかできません。

ある程度進んだところで、「疲れた」という声が出ました。よくわからないものを手探りで進むのは、疲れて当然です。

そこで気分転換に、できたところまでをテスター（電気が通っているかを測る道具）で導通確認してみました。自分の作った回路が正しくつながっているかを確かめながら進められるので、手探りの中にも少し手応えが生まれます。

いつものパソコン解体班

こちらはいつものパソコン修理班です。

わたしもコメントするネタが無くなってきました。これからパソコン自作や修理をしたい人は、光都ICTクラブにくれば、実地で勉強できるかもね。

3Dプリンター初造形

光都ICTクラブのメンバーは実力があるので、3Dプリンターの使い方を一から手ほどきすることはしません。「3D CADでデータを用意して、スライスしてプリントすればいいんだよ」と大まかな流れを伝えるだけです。あとは自分で調べながら進める。それが光都ICTクラブのメンバーのスタイルです。

今回は、実在する車の3Dデータをどこからか見つけてきたというので、まずその中身を一緒に確認しました。続いてデータをSTL形式（3Dプリンターで扱う標準的なファイル形式）でエクスポートし、3Dプリンター付属のソフトでスライスします。スライスとは、立体を薄い層に切り分けて、プリンターが一層ずつ積み上げられる命令に変換する作業です。そのデータをプリンターに送り、出来上がりを待ちます。

ソフトが最初に示した造形時間は4時間でした。それを本人がモデルを縮小するなどして、50分で終わるように調整していました。

元のデータがあるなら簡単だろう、と思われるかもしれません。ところが実際には、この印刷に2回ほどやり直しています。原因は「サポート」という考え方を知らなかったことです。3Dプリンターは下から順に積み上げていくので、宙に浮いた部分があると、その下に支えとなる仮の柱（サポート）を一緒に造形しなければなりません。これがないと、空中に樹脂を出すことになり、造形が崩れてしまいます。プリント中にぐちゃぐちゃになる事態を、2回繰り返しました。

そこでホワイトボードでサポートの考え方を簡単に説明し、ソフトの中にその設定項目があることを見せました。あとは本人に任せます。

すると、クラブの活動時間の2時間の中で、思い描いていた車の造形が出来上がりました。

ただし、表面はガタガタです。思った通りの滑らかな車ができたわけではありません。時間を縮めるためにモデルを小さくしたことも、関係しているのかもしれません。ここをどうすればよくなるのかは工夫のしどころで、本人が考えるべきところです。

こうした面白さや、根気よく試行錯誤を重ねる作業は、プログラミングにも通じます。むしろプログラミングでそれを身につけているからこそ、3D造形でも同じように工夫を繰り返せるのだと思います。分野が違っても考え方は相通じる。それはエンジニアリングの基本なのかもしれません。

生成AIが勝手に思い通りに作ってくれるわけじゃない

レトロゲームが好きなメンバーが、初代ファミコンの某RPG風のゲームをPythonで作っています。元のゲームのコードを真似ているわけでも、どこかから持ってきているわけでもありません。見た目を似せて、コードは一から自分で書いています。すべての学びは模倣から始まります。ここから自分のアイデアを足していけばいいのです。

その彼から「キー入力に対して動きが遅いんだけど、どうすればいいの」と聞かれました。私の返事は「それこそAIに聞いてみればいい」です。

ただ、AIにどう聞くか、どうやって良い回答を引き出すかには、テクニックと腕がいります。AIに頼めば、こちらが思い描いた通りのものを全部作ってくれるわけではありません。特にゲームでは、思っていたのと違う動きや形が当たり前に出てきます。それを微調整していくことが大事で、そのためにはコードも読まなければなりません。生成AIに絶妙な指示を出していくのは、難しいところでもあります。

キー入力のレスポンスが遅い件は、AIに解決策を探してもらい、それを採用することで解決しました。

続いて「マップが小さいので大きくしたい」というので、大きなマップを表示するコードを書いているのが下の写真です。

マップは配列の0と1で描きます。0が何もないところ、1が障害物のあるところ、という具合です。さらにこの配列をいくつも重ね合わせて、木のあるところ、山のあるところ、草原、海、と描き分けていく、というのがAIの回答でした。私はこの分野にはあまり詳しくないので、「こういうものはこうやって作るのか」と感心しながら回答を読んでいました。

ただ、配列が増えればプログラムは大きくなります。ファミコンのような昔の機種に、これがそのまま全部載っていたとは思えません。何らかの工夫があったはずで、それをどうしていたのか、私は気になっていました。彼がそこまで感じていたかはわかりませんが、そういうところも、おいおい考えていってほしいと思っています。

ところで、マップを大きくしたら新しい問題が出ました。「キャラクターが動いているのか、マップが動いているのかわからない」というのです。「どうしたらいい？」とまた聞いてきたので、ここでも「それこそAIに聞いてみて」と返しました。彼はごそごそと調べ始めます。

しばらく様子を見ていると、彼が「なるほどね」と大きな声を上げました。キャラクターが画面の同じ位置にいて背景だけが動く場合、その背景が一様だと、本当に移動しているのかどうかわかりません。そこで、キャラクターに同じ場所で足踏みをさせることで、移動していることを表現する。そういう答えをAIから引き出したようです。

その場で足踏みをするから、動いているように見える。かつてのファミコンのゲームを作った人たちは、そういう表現を生み出したのでしょう。彼はそれを知って「なるほど」と感じたわけです。私もすごいなと思いました。

これこそが学びだと思います。先人の知恵に自分で気づくことは、とても深い学びです。彼自身も「ゲームをしているだけのときは、ずっと足踏みしていて落ち着きがないなと思っていたけど、作る側になって初めて意味があったとわかった」と言っていました。いい学びになったと思います。