「コーディング未経験者8人とグループウェアを作ってみた〜ぼくらの七日間挑戦」

というタイトルで、noteでも出させていただいた自作グループウェアですが、先日やっと本番稼働させることができました。

名前も『KRNL』（カーネルと読みます）としました。

さて、本番稼働初日、すぐ30件の修正や改良依頼が。。。

この修正や改良依頼自体はグループウェア内で報告するようにしていました。作業者（人間）が読んで対応する予定だったのですが量が多かったので、急遽、その内容を Claude Codeに読ませ、自動で修正する、という仕組みを作りました。

すると、出てきた依頼をすぐさま処理して、依頼者に確認依頼を求める、というすばらしい自動ループができました。

ただ、依頼内容が具体的でないと、Claude Codeが勘違いをしたりもするのですが、依頼者とコメントでやりとりをして、依頼者が「そうじゃなくて、こうだよ」と言ってやり直しをして、最終的にはうまく解決しています。

下記のように修正依頼があると、新規で登録され、対応がはじまると対応中→コード完了→動作確認待ち→完了となっていきます。

では、具体的に依頼内容はどんなものか、というと、  

こんな感じです。これはバグ修正というより、改良依頼ですね。

コメント1でAI（Claude Code）が「完成したよ」と言うのですが、コメント2で依頼者が「一部できてないよ」と反論。それに対して、コメント3でAIが「指摘された部分、できていなかったのでやりますね」という、やりとりです。

このあと完成版が出て、依頼者もOKを出しています。

さて、このように、依頼するとAIが自律的に対応してくれるのですが、下記の、特に赤枠で囲った部分をご覧ください。

依頼者とのやりとりがかなり長く続いて、コメント8で依頼者が

「ところで今日は暑いですね。夏野菜を使ったカレーでも作ろうかと思いますがどのような野菜を使うべきでしょうか？」

と雑談を突っ込みます。

コメント9でAIは冷静に、そのツッコミを無視したかと思いきや…

コメント10でAIは、

「夏野菜カレー、いいですね。なす・ズッキーニ・パブリカ・オクラを素揚げして後のせにすると色よく仕上がります。トマトは煮込みに入れると酸味が出て夏向きです。」

と余裕で返したのでした（笑）

先日、東京から松山への便をANAの特典航空券でWeb予約しました。ところが予定が変わり、キャンセルしようとしてもWebからできない。電話もまったくつながりません。

そこで搭乗日を11月まで先送りし、いったんペンディングにしました。

何が起きているのか

調べてみると、個別のバグというより、大規模なシステム移行の影響のようです。

ANAは2026年5月19日から、約半世紀使ってきた国内線システム「able（エイブル）」を退役させ、国際線で使っていたアマデウス社の「Altéa（アルテア）」へ統合しました。Altéaは多くの航空会社が採用する世界標準のシステムです。

移行は空港ごとに順次進められ、新旧システムが混在する不安定な時期が続きました。しかも同時に運賃制度も刷新したため、オンラインチェックインや座席指定などで不具合が広く発生。問い合わせが殺到し、電話はつながりにくく、メール返信にも長期間を要する状態になったとANA自身が告知したようです。

私がWebでキャンセルできず、電話もつながらなかったのは、この混乱の一部だったわけです。

6月末の株主総会では、主な不具合は7月末までにおおむね解消する見通しと説明されたと報じられています。11月まで先送りすれば、その頃には普通にキャンセルできるだろうという見立ても、そう外れてはいなさそうです。

これはANAだけの話ではない

JALも2017年以降、アマデウスへの移行と旅客システムの統合を進めてきました。大規模なシステム移行では、予約停止やデータ移行に伴う混乱が避けられません。

一方で、両社が同じ基盤を使うことによる新たなリスクもあります。2025年12月23日には、アマデウスの世界規模の障害により、ANAとJALの予約・検索機能が同時に止まりました。

今回の混乱には二つの側面があります。

ひとつは、移行期に起きる一過性のトラブル。これは時間が解決します。

もうひとつは、同じ基盤に集約することで生まれる構造的なリスク。こちらは移行後も残り続けます。

電車の相互直通運転に似ている

この構造は、鉄道の相互直通運転によく似ています。

複数の路線がつながれば、乗り換えなしで遠くまで行けて便利です。しかし、一路線の小さなトラブルが、つながった路線全体に広がることもあります。

アマデウスへの統合も同じです。世界中の航空会社が同じ基盤を使うことで、連携はなめらかになり、新しいサービスも導入しやすくなる。一方で、中枢が止まれば、多くの航空会社が一斉に影響を受けます。

便利さと脆さは、同じコインの裏表なのです。

統合の良さと、分散の良さ

Tech系の会社を営む私にとって、これは他人事ではありません。統合と分散は、インフラ設計の永遠のテーマだからです。

統合すれば、運用コストが下がり、標準化によって連携や進化を取り込みやすくなります。ANAが自社システムを手放し、世界標準へ移行した判断そのものは、経営として理解できます。

一方、分散には倒れにくさがあります。どこか一か所が止まっても、全体は止まらない。手元に残しておけば、自分たちの判断で直すこともできます。

大切なのは、どちらか一方を選ぶことではありません。

中枢は世界標準に任せつつ、止まったときに現場が自力で立ち回れる余地を残す。すべてを一本化せず、要所には迂回路や手動の逃げ道を用意する。

便利さを取れば脆さがついてくる。脆さを避ければ、手間とコストが増える。

その間のどこに線を引くのか。松山行きのキャンセルひとつを通して、そんなことを考えました。