はじめに
2025年9月、私はQiitaに「AIによるシフト表作成」という記事を投稿しました。
当時は、2025年8月の病棟シフト表をChatGPT 4o mini、Claude Sonnet 4、ChatGPT 5、Geminiに作成させ、結果を比較しました。25人について31日分の勤務を割り当て、夜勤人数、休日数、禁止する勤務の並び、夜勤ペア、男女構成、連続勤務などの条件を与えたものです。
しかし、各AIの出力には複数の条件違反や不整合が見つかり、指定した条件をすべて満たす勤務表を作成することはできませんでした。結論は「AIに完成したシフト表を直接出力させる方法は実用的ではなく、専用の数理最適化モデルが必要」というものでした。
それから約1年。2026年8月時点のAIは、同じ課題をどこまで解けるのでしょうか。
今回は、前回と同じ2025年8月を題材に、条件を少しずつ変えながら複数回依頼しました。
使用したモデルは、2026年8月時点のGPT-5.6 Solです。
先に結論を書くと、2026年8月時点のAIは、条件が十分に定義されていれば、制約を満たすシフト表を作成し、機械的に検証するところまで実行できました。
ただし、それはAIが巨大な表を勘だけで正しく書けるようになった、という意味ではありません。AIの使い方そのものが変わったことが、今回の結果を理解するうえで重要です。
2025年の検証で起きたこと
元記事では、複数のAIに同じ条件を提示し、病棟勤務表を作成させて、その正確性を比較しました。
主な条件は次のとおりです。
- 看護師25人、対象期間は2025年8月1日から31日
- 毎日、夜勤2人と早番1人を配置
- 各スタッフの休日は10～12日
- 男性スタッフだけの夜勤は禁止
- 特定スタッフ同士の同時夜勤は禁止
- 6連続勤務以上は禁止
- 土日の日中勤務者は7人
一つひとつの条件は明確でも、勤務の割り当ては相互に影響します。たとえば夜勤を1か所変更すると、翌日の夜勤明け、その後の休日、日中の勤務者数、連続勤務数なども変化します。
2025年の検証では、こうした条件を同時に満たす勤務表を作成することができませんでした。出力された表には、6連続勤務以上、禁止する勤務の並び、必要人数の不足などの条件違反があり、さらに集計値と実際の勤務割り当てが一致しないケースもありました。
特に、集計行には夜勤者数が「2」と表示されていても、実際にその日の勤務を数えると2人ではない例がありました。表の見た目や集計結果だけでは、条件が本当に守られているか判断できないことも、2025年の検証で明らかになった問題でした。
2026年8月の再検証
2026年8月の再検証では、元記事と比較するため、同じ2025年8月の病棟勤務表を対象としました。元記事と同一条件での再挑戦に加え、各スタッフの希望勤務を反映するケースと、意図的に条件を矛盾させたケースも検証しました。
最大の変化は、2025年の検証では実現できなかった、指定した必須条件をすべて満たす勤務表を生成できたことです。以下では、三つの再検証を通して、その結果を紹介します。
再検証1：2025年と同じ条件で勤務表の作成に成功
再検証1では、比較条件を変えないため、元記事で各AIへ渡した共通プロンプトをそのまま使用しました。看護師25人、女性23人・男性2人、31日間、毎日夜勤2人・早番1人、休日10～12日、禁止する勤務の並び、禁止する夜勤ペア、土日の日中勤務者7人など、条件は同一です。
2025年の検証では、AIは制約を踏まえたヒューリスティックなルールに基づいて勤務を配置しており、最適化コードを実行して勤務表を作成したものではありませんでした。一方、今回の再検証では、生成方法や使用するソルバーを指定していなかったにもかかわらず、AIが条件を数理最適化モデルとして定式化し、SciPyのmilpを介してHiGHSで勤務表を求解しました。
必須条件を制約として設定し、平日の日中勤務者数のばらつきや、連続勤務・連休を抑えるように最適化しました。
その結果、2025年の検証では作成できなかった、明示した必須条件をすべて満たす勤務表を作成できました。
完成後には、AIが一連の作業の中で作成した検証処理を使い、勤務の並び、日別人数、休日数、禁止ペア、連続勤務などの必須条件を再計算し、違反がないことを確認しました。2025年の検証で問題になった、集計値と実際の割り当ての不一致についても、AIが作成した検証処理で再計算し、問題がないことを確認しました。
再検証2：スタッフ情報をExcelから読み込み、複雑な条件でも作成に成功
再検証2では、スタッフの属性と勤務希望が入力されたExcelファイルを読み込み、その内容を勤務表へ反映できるかを確認しました。さらに、再検証1よりも条件を複雑にするため、夜勤を3人体制とし、遅番、長日勤、日勤リーダーの配置などの条件を追加し、条件が複雑になってもAIが勤務表を作成できるかを検証しました。
Excelファイルには、25人分について次の情報を入力しました。
- 氏名
- 性別
- 日勤リーダーの可否
- 8月1日～31日の希望勤務
（この再検証で必須条件として反映した希望勤務は「休」のみ）
生成方法については指定しませんでした。その結果、AIは数理最適化モデルを構築するのではなく、Pythonで勤務を順次配置・調整するヒューリスティックな処理を実装しました。この方法では、条件を満たす解は得られても、最適解であることは保証されません。
最初に作成したコードは、初回の実行では条件を満たす完成表を生成できず、約98.9秒で処理を終了しました。その後、AIがコードを修正して再実行し、最終的にはExcelの勤務希望を反映し、追加した条件も満たす勤務表を作成できました。
完成後には、AIが一連の作業の中で作成した検証処理を使い、勤務希望、必要人数、勤務の並び、禁止ペア、休日数、連続勤務などの必須条件を再計算し、違反がないことを確認しました。
このケースでは、依頼開始から完成表の提示まで約11分8秒かかりました。これは最終的な計算時間ではなく、Excelファイルの読み取り、コードの作成・修正・再実行・検証を含む時間です。
再検証3：希望勤務をすべて反映し、成立しない条件も判定できるか
再検証3では、再検証2よりさらに条件を複雑化し、「休」だけでなく、その他の勤務希望もすべて必須条件としたうえで勤務表を作成できるかを確認しました。さらに、意図的に矛盾した希望を与えた場合に、不成立を正しく判定し、その原因まで説明できるかを検証しました。
再検証1では数理最適化、再検証2ではヒューリスティックな方法が選択されており、生成方法を指定しなければAIがどの解法を選択するかは一定しません。そこで今回は、検証方法を固定するため、HiGHSによる数理最適化を使用するよう明示しました。
希望勤務をすべて必須条件としたまま作成に成功
一つ目の検証では、Excelの空欄以外の希望勤務をすべて必須条件としました。対象は、「休（休日）」「日（日勤）」「長（長日勤）」「夜（夜勤入り）」「明（夜勤明け）」「早（早番）」「遅（遅番）」で、いずれも変更不可として数理最適化しました。
その結果、HiGHS 1.15.1で最適解が得られました。求解後には、AIが一連の作業の中で作成した検証処理を使い、希望勤務との一致を含む必須条件を再計算しました。希望勤務違反0件、必須条件違反0件となり、希望勤務を変更せずに勤務表を作成できました。
HiGHSの求解時間は4.60秒、最適化スクリプトの実行全体は約6.85秒でした。Excelファイルの読み込み、モデル作成、HiGHSの実行準備、検証までを含むAIの作業全体では約4分58秒かかりました。
意図的な矛盾を正しく検出できるか
次に、AIが条件の矛盾を判別できるか確認するため、8月4日に25人全員が「休」を希望するデータを意図的に用意しました。
すべての希望勤務を必須条件として固定すると、8月4日に必要な勤務者を配置できないため、HiGHSはすべての条件を同時に満たす解は存在しないと判定しました。
その後、AIが入力条件と制約を調べ、8月4日の全員休希望と必要な勤務者数の条件が衝突していることを特定しました。勤務表を無理に完成させるのではなく、作成できないことと、その原因を示すことができました。
この検証では、依頼開始から原因の切り分けと不成立レポートの作成まで約7分3秒かかりました。
条件を無断で緩和した試行もあった
同じ不成立データを使った別の試行では、すべての条件を同時に満たせないと判定した後、AIが休み希望を必須条件から努力条件へ変更し、128件中121件を反映した最適解を作成しました。
しかし、この条件変更について利用者の了承は得ていませんでした。そのため、この結果は元の依頼を満たした成功例ではなく、希望を緩和すれば成立することを示した参考解です。
ここで得られた最適解は、あくまでAIが条件を変更した後の数理モデルに対する最適解であり、元の依頼条件をすべて守ったことを意味しません。
この検証では、希望勤務をすべて必須条件とした場合でも条件を満たす勤務表を作成できること、また、条件そのものが矛盾している場合には不成立を判定し、その原因まで示せることを確認しました。一方で、条件を緩和して参考解を作成する場合には、元の依頼とは明確に区別し、利用者の了承を得る必要があります。
何が変わったのか
1. 完成表を直接出力するだけではなく、作成過程そのものを担えるようになった
2025年の検証では、AIに条件を提示し、完成した勤務表を直接出力させていました。
今回の再検証では、AIが条件を整理し、それをコードへ変換し、勤務表を生成する処理を作成して実行しました。さらに、うまくいかなければコードを修正して再実行し、完成後には条件違反の検証まで行いました。
つまり変わったのは、AIが巨大な勤務表を直接正確に書けるようになったことではありません。条件整理、コード作成、実行、修正、検証という複数段階の作業を一連の流れとして進められるようになったことが大きな変化です。
今回の使い方は、単に質問に対して回答を返すだけではなく、目的に沿って複数の処理を進めるという意味で、AIエージェント的な使い方といえます。
2. 「それらしい表」ではなく、機械的に検証できる成果物になった
完成した勤務表を目視しただけでは、すべての条件が守られているかを確認することは困難です。
2025年の検証では、集計欄には「夜勤2人」と表示されていても、実際に各日の勤務を数えると人数が一致しない例がありました。
今回は、勤務表を生成する処理だけでなく、条件違反を確認する検証処理もAIが作成しました。そのため、休日数、日別の必要人数、禁止する勤務の並び、禁止ペア、連続勤務、希望勤務との一致などを、完成した勤務表から再計算して確認できます。
勤務表そのものを信用するのではなく、別の処理で条件を再計算して確認できるようになったことは、実用性を考えるうえで大きな違いです。
また、再検証3では、すべての条件を同時に満たせないケースについて、勤務表を無理に完成させるのではなく、不成立であることを判定し、衝突している条件を特定するところまで確認できました。
3. AIと数理最適化の役割が変わった
前回の記事では、「完成した勤務表をAIに直接出力させるのではなく、専用の数理最適化モデルを使うべき」という結論でした。この点は現在も変わりません。
多数の制約を確実に守りながら、公平性や希望の反映などを評価して勤務表を作成するには、数理最適化は依然として有力な方法です。
一方、今回の再検証では、利用者が最適化モデルを最初から実装しなくても、AI自身が条件を数理モデルへ変換し、SciPyやHiGHSを利用して勤務表を求めることができました。また、数理最適化を使用しないケースでも、AIがヒューリスティックな生成処理と検証処理を作成しました。
つまり、AIと数理最適化のどちらを使うか、という関係ではなく、AIが数理最適化モデルやその周辺処理を作る役割を担えるようになったと考える方が、今回の結果を正確に表しています。
今回の再検証から、少なくとも今回使用したGPT-5.6 Solとコード実行環境の組み合わせでは、条件を明確に提示することで、制約を満たす病棟勤務表の作成から検証までを一連の作業として実行できることを確認しました。
ただし、「すべての必須条件を満たした」という結果は、あくまで今回指定し、検証処理に組み込んだ条件に対するものです。実際の病棟では、必要人数や勤務の並びだけでなく、スタッフの経験、組み合わせ、公平性、個別事情など、勤務表に反映すべき条件はさらに多くなります。それらを適切に定義し、生成処理と検証処理へ反映したうえで、最終的には人が確認する必要があります。
この1年で最も大きく変わったのは、AIが勤務表を一度の応答だけで正確に書けるようになったことではありません。AIが、条件整理、コード作成、実行、修正、検証までを一連の作業として進めるAIエージェント的な役割を担えるようになったことです。