同じコードから、2台のパソコンで違うサイトが出来上がった — 中小企業 × AI 経営（2026年8月）

結論から言うと、「同じ材料から同じものが出来る」というのは、放っておいて成り立つ性質ではありませんでした。

弊社は自社サイトを内製で運用しています。原稿を書き、それをプログラムがページに組み立てて公開する、という形です。長らく私の作業マシン1台で回してきました。

先日、事業継続のために2台目のマシンを用意しました。1台が壊れても止まらないようにするためです。同じプログラム、同じ原稿、同じバージョン。当然、同じサイトが出来ると思っていました。

出来上がったものを1台目と比べたところ、49ページが食い違っていました。

エラーは1つも出ていない

まず気味が悪かったのは、どちらも正常に完成していることでした。

エラーは出ません。警告もありません。ページ数も同じ。にもかかわらず、中身の一部が違う。片方にだけ表示されている情報がある、という状態です。

どちらが正しいのか。答えは「どちらも正しくない」でした。正確には、どちらでもありえたのです。

原因：並び順を、誰も決めていなかった

調べた結果、原因は拍子抜けするほど単純でした。

研修ページの下部に「関連する研修」を6件表示しています。この6件は、全部の研修から条件に合うものを取り出して、先頭から6件を載せる作りでした。

問題は、その「全部の研修」を取り出したときの並び順を、誰も指定していなかったことです。

指定していない場合、順番はプログラムが原稿ファイルを見つけた順になります。そしてこの「見つけた順」は、パソコンの中でファイルがどう並んでいるかに左右されます。同じファイルを同じ数だけ持っていても、いつ・どんな順で保存されたかによって、並びは変わりうるのです。

つまりこうなっていました。

	1台目	2台目
原稿ファイル	完全に同じ	完全に同じ
プログラム	完全に同じ	完全に同じ
取り出したときの並び	A, B, C, D, E, F, G…	C, A, G, B, F, D…
先頭6件	A〜F	C〜D
表示される関連研修	この6件	違う6件

「6件に絞る」という処理そのものは正しく動いています。絞る前の並びが決まっていなかったので、絞った結果が変わっただけです。

境目がなければ問題は表に出ませんでした。全部載せるなら順番が違っても内容は同じです。「上位◯件だけ」という切り方をした瞬間に、決めていなかった並び順が結果を左右し始めたわけです。

1台で運用していた間、これは「無かった」

ここが今回いちばん考えさせられた点です。

このプログラムは何か月も動いていました。その間、この問題は一度も表面化していません。1台で動かしている限り、同じマシンなら並び順もだいたい同じなので、結果も安定して見えます。

問題は最初から存在していて、比べる相手がいなかったから見えなかっただけです。

これは会社の業務でもよく起こります。ずっと同じ人がやっている作業は、手順書が不十分でも回ります。その人の中に順番が入っているからです。**2人目がやろうとした瞬間に、書かれていなかった部分が初めて問題になる。**今回の一件は、それがプログラムの世界で起きたのと同じでした。

だから私は、この不具合を「2台目を作ったせいで発生した問題」とは考えていません。2台目を作ったから見つかった問題です。むしろ見つけられて良かった類のものでした。

直し方：入口を1つにする

対処として、原稿を取り出す処理を1か所に集約し、そこで必ず並び順を明示するようにしました。

やり方は他にもありました。表示している箇所を全部探して、それぞれに並び替えを足していく方法です。実際、最初はそれを考えました。

ただ弊社では、こう決めています。

直すときは、呼んでいる場所を全部直すのではなく、共通の入口に1つガードを置く。

理由は単純で、個別に直すと必ず抜けが出るからです。今回直した箇所は数か所でしたが、今後ページを増やすときに、新しい場所で同じ間違いをやり直す可能性が残ります。入口を1つにしておけば、そこを通る限り並び順は保証されます。

直したあと、2台で作った結果が621ファイルすべて一致することを確認しました。「たぶん直った」ではなく、実際に全部を突き合わせています。今回のように「エラーが出ないまま結果だけ違う」種類の問題は、確かめない限り直ったかどうか分からないためです。

さらに、2台の結果を比べる作業自体を、いつでも実行できるコマンドにしました。次に何かを変えたとき、また食い違いが起きていないかをすぐ確認できます。1回の調査で終わらせず、繰り返せる形にして残す——これは弊社が何度か痛い目に遭って身につけた習慣です。

中小企業にとっての意味

「再現性」という言葉は、製造業では当たり前に使われます。同じ材料と同じ手順から同じ品質が出ることが、品質保証の前提だからです。

ソフトウェアやオフィス業務では、この感覚が抜けがちだと感じています。動いていれば正解に見えるからです。

しかし実際には、次のようなことが起きます。

• 担当者のパソコンでだけ動く手順書
• 人によって微妙に違う集計結果
• 「なぜかこの端末だと数字が合わない」

いずれも書かれていない前提が、どこかに紛れ込んでいる状態です。1人で回している間は問題になりません。人が増えたとき、機械が増えたとき、初めて姿を現します。

そして厄介なことに、**この種の問題はエラーを出しません。**警告も出ない。ただ結果が違うだけです。だから「気づく仕掛け」を持たない限り、いつまでも見つかりません。

私が今回やったことを一般化すると、こうなります。

やったこと	業務に置き換えると
2台で作って突き合わせた	2人にやらせて結果を比べた
並び順を明示した	手順書に「順番」まで書いた
入口を1つにした	作業の入口を1つの様式に統一した
比較をコマンドにした	突き合わせを定期チェックに組み込んだ

「2人にやらせて結果を比べる」は、地味ですが効きます。手順書の抜けを見つける方法として、これ以上に確実なものを私は知りません。

余談：2台目を持つということ

もともと2台目を用意したのは、機材が1台しかない状態が事業継続の観点で危ういと考えたからでした。壊れたら止まる、という状態を放置していたわけです。

結果として、故障への備えという当初の目的に加えて、「自分たちの仕組みに書かれていない前提がどれだけあるか」を測る道具が手に入りました。

冗長化というと保険のように語られますが、実際には品質を確かめる手段でもあった、というのが今回の実感です。1台では、自分が正しいかどうかを比べる相手がいません。