はじめに さくらのナレッジ編集部の法林です。 2026年8月1日(土)に、さくらインターネットの大阪本社でもあるBlooming Campにおいて「きのこカンファレンス 2026 in 関西」が行われました。本記事ではこ […]

本ブログは 2025 年 8 月 4 日に公開された Amazon Science Blog “ Three challenges in machine-based reasoning ” を翻訳したものです。 自然言語から構造化された言語への変換、真理の定義、そして確定的な推論は、自動推論において依然として中心的な課題です。しかし、Amazon Web Services の新しい自動推論チェック (Automated Reasoning checks) は、これらすべてに対処するのに役立ちます。 生成 AI の登場により、自動推論の分野に携わってきた私の 30 年以上のキャリアの中で、ここ数年は最も刺激的な時期になっています。なぜでしょうか。コンピュータ業界、さらには一般の方々までもが、論理の分野に携わる私たちが長年情熱を注いできたアイデアについて、今や熱心に語るようになったからです。言語、構文、意味論、妥当性、健全性、完全性、計算複雑性、さらには決定不能性といった課題は、かつては学術的で難解すぎて、多くの人々には縁のないものでした。しかし、状況は一変しました。これらのテーマに触れ始めたばかりのみなさん、ようこそ。ぜひ足を踏み入れてください。一緒に取り組めることを楽しみにしています。 本記事では、AI システム (例えばチャットボットのような生成 AI ベースのシステム) で正しい推論を実現する際に、最も厄介だと私が考える 3 つの側面を紹介します。Amazon Bedrock Guardrails の自動推論チェック機能をリリースした背景には、まさにこれらの難題がありました。とはいえ、まだ道半ばです。これらの問題には本質的な難しさがあるため、私たちはコミュニティとして (そして自動推論チェックのチームとして)、この先も長年にわたってこれらの難題に取り組み続けることになるでしょう。 難題 1: 自然言語から構造化された言語への変換 人間は通常、厳密さに欠けるあいまいな言葉でやり取りしています。多くの場合、文脈からあいまいさを解消する情報を補って理解できます。本当に重要な場面では、「～という意味でしょうか」と互いに確認し合うこともあります。しかし、本当に確認すべき場面であっても、そうしないこともあります。 これはしばしば混乱と対立の原因になります。ある雇用主が、従業員向け福利厚生の受給資格を「フルタイム換算 (FTE) 0.2 以上の雇用契約を有していること」と定義しているとしましょう。ここで私が「手術を受けた家族の回復を支えるために昨年休みを取った期間を除き、自分の時間の 20% を仕事に費やしています」と伝えたとします。私はこの福利厚生を受ける資格があるでしょうか。「自分の時間の 20% を仕事に費やしている」という発言は、雇用契約のもとで、労働時間の 20% に相当する時間を働いているという意味なのでしょうか。 私の発言には複数の合理的な解釈が成り立ち、解釈によって受給資格の結論が変わります。自動推論チェックでは、相補的ないくつかのアプローチを用いて、自然言語とクエリ述語の間の変換を複数回試みます。これはインタビューでよく使われる手法と同じです。同じ情報を異なる方法でたずね、事実が一貫しているかどうかを確かめるのです。自動推論チェックでは、形式論理体系のソルバーを使って、異なる解釈が等価であるかどうかを証明または反証します。変換結果が意味のレベルで食い違っていれば、自動推論チェックを利用するアプリケーションは、ユーザーに確認を求めることができます (例: 「フルタイムの 20% 以上の雇用契約があることを確認していただけますか」)。 自動推論チェックは、大規模言語モデルを使用して、自然言語を形式言語へ変換した複数の候補を生成します。変換結果の間に食い違いがあれば自動推論チェックがそれを指摘し、お客様は自然言語による対話を通じて解消できます。 難題 2: 真理の定義 いつも驚かされるのは、ルールの意味について複数の人が合意することがいかに難しいかという点です。複雑なルールや法律には微妙な矛盾が潜んでいることが多く、誰かがその解釈について合意を形成しようとするまで見過ごされることがあります。例えば、英国の 1988 年著作権・意匠・特許法 (Copyright, Designs and Patents Act 1988) には本質的な矛盾があります。著作権の対象となる著作物を著作者自身の知的創作から生じたものと定義する一方で、人間の創造的な関与を必要としない著作物にも保護を与えているのです。この不整合は、AI が作品を生成する現代において、とりわけ目立つものになっています。 2 つ目の問題は、私たちがルールを絶えず変え続けているように見えることです。例えば、米国連邦政府の日当 (per diem) の額は毎年変更されるため、その値に依存するシステムは常に保守が必要になります。 最後に、自分が従うべきルールのコーナーケースをすべて深く理解している人はほとんどいません。運転中のイヤホン装着を例に考えてみましょう。米国では、アラスカ州のように違法な州、フロリダ州のように片方のイヤホンだけなら合法な州、そしてテキサス州のように問題なく合法な州があります。友人や同僚に非公式に聞いてみたところ、直近で車を運転した場所において、運転中のヘッドホン装着が合法かどうかを自信を持って答えられた人は、ごくわずかでした。 自動推論チェックは、税法、人事ポリシー、その他のルール体系といったお客様の関心領域において何を真理とするかを定義できるよう支援し、さらにルールの変更に合わせてその定義を継続的に洗練する仕組みを提供することで、これらの難題に対処します。生成 AI ベースのチャットボットが登場したとき、私たちの多くが想像力をかき立てられたのは、複雑なルール体系を自然言語のクエリで一般の方々にも利用できるようにする、という発想でした。将来、チャットボットは「日本の東京で運転中に U ターンできますか」といった質問に、端的でわかりやすい回答を返せるようになる可能性があります。真理を定義するという難題に取り組むことで、自動推論チェックはその回答の信頼性を確保するのに役立ちます。 自動推論チェックのユーザーインターフェイス。 難題 3: 確定的な推論 ルールの集合 (これを R と呼びます) と、検証したい文 ( S ) があるとします。例えば、 R はシンガポールの交通規則、 S はシンガポールの交差点での U ターンに関する質問だとしましょう。 R と S は、ブール変数をさまざまに組み合わせることで、コンピュータが理解できるブール論理へエンコードできます。 R と S のエンコードに必要なのはわずか 500 ビット、およそ 63 文字だとしましょう。ごく小さな情報量です。しかし、ルール体系のエンコードがテキストメッセージに収まるほど小さくても、チェックすべきシナリオの数は天文学的な規模になります。理論上は、2 500 とおりの組み合わせをすべて検討しなければ、 S が真であると断定することはできません。今日の高性能なコンピュータは、まばたきをする間に数億回の演算を実行できます。しかし、世界中のコンピュータをこの猛烈な速度で宇宙の始まりから動かし続けていたとしても、2 500 とおりの可能性をすべてチェックし終えるには、今日に至ってもなお程遠いでしょう。 ありがたいことに、自動推論のコミュニティは SAT (充足可能性問題) ソルバーと呼ばれる高度なツール群を開発してきました。これによって、この種の組み合わせのチェックが可能になり、すべてではないものの、多くのケースで驚くほど高速に実行できます。自動推論チェックは、文の妥当性を検証する際にこれらのツールを活用しています。 残念ながら、あらゆる問題を SAT ソルバーの強みが生きる形でエンコードできるわけではありません。例えば、あるルール体系に次の規定があるとしましょう。 「2 より大きいすべての偶数が 2 つの素数の和であるならば、源泉徴収税率は 30% とし、そうでなければ 40% とする」 。問題は、源泉徴収税率を知るには 2 より大きいすべての偶数が 2 つの素数の和であるかどうかを知る必要があるのに、それが真かどうかを現時点で誰も知らないという点です。この命題はゴールドバッハ予想と呼ばれ、1742 年以来の未解決問題です。とはいえ、ゴールドバッハ予想の答えはわからなくても、それが真か偽のいずれかであることは確かです。したがって、源泉徴収税率は 30% か 40% のいずれかでなければならない、と確定的に言えます。 自動推論チェックを利用するお客様が、自動推論チェック自身の判定結果に依存するポリシーを定義できるかどうかを考えてみるのも面白いところです。例えば、次のルールをポリシーとしてエンコードすることは可能でしょうか。 「アクセスは、自動推論チェックが『許可されない』と判定した場合、かつその場合に限り許可される」 。この場合、正しい答えは存在しません。このルールは自身のチェック手続きを再帰的に参照することで矛盾を生み出しているからです。ここでできる最善の対応は「不明 (Unknown)」と答えることです (実際、このケースで自動推論チェックが返す答えも「不明」です)。 訳注: 2026 年 9 月時点の Amazon Bedrock ユーザーガイドでは、自動推論チェックの検証結果は VALID、INVALID、SATISFIABLE、IMPOSSIBLE、TRANSLATION_AMBIGUOUS、TOO_COMPLEX、NO_TRANSLATIONS の 7 種類として定義されており、「不明 (Unknown)」という結果値はありません。ポリシーの矛盾により判断できない場合は IMPOSSIBLE が返されます。参照: 自動推論チェックの概念 – Amazon Bedrock 自動推論チェックのようなツールが、こうした文に対して「真」も「偽」も返せないという事実は、1931 年に Kurt Gödel によって初めて示されました。Gödel の結果からわかるのは、自動推論チェックのようなシステムは無矛盾性と完全性を同時に満たせず、どちらかを選ばなければならないということです。AWS は無矛盾性を選びました。 自然言語を構造化された論理へ変換すること、絶えず変化し、時には矛盾するルールのもとで真理を定義すること、確定的な推論の複雑さに立ち向かうこと。この 3 つの難題は、健全な推論を備えた AI システムを構築する際に直面する単なる技術的ハードルにとどまりません。いずれも、私たちの技術の限界と、人間が作る仕組みの複雑さの両方に深く根ざした問題です。 2025 年 8 月 6 日の Amazon Bedrock Guardrails における自動推論チェックのリリースを機に、AWS は相補的なアプローチを組み合わせてこれらの難題に取り組んでいます。具体的には、あいまいな自然言語から論理述語へ変換するためのクロスチェック手法を適用すること、お客様によるルール体系の開発と保守を支援する柔軟なフレームワークを提供すること、そして確定的な回答が得られないケースを慎重に扱いながら高度な SAT ソルバーを活用することです。これらの難題に対する製品の性能を高めていく中で、AWS は技術を前進させるだけでなく、Gödel の不完全性定理から、変化し続ける法律やポリシーの枠組みのあり方に至るまで、推論そのものを形作ってきた根本的な問いへの理解も深めています。 健全な推論を提供するというコミットメントを踏まえれば、AI 分野における今後の道のりは険しいものです。その挑戦を受けて立ちます。 著者について Byron Cook Amazon の vice president 兼 distinguished scientist である Byron Cook は、形式的検証分野のリーダーであり、SAT、SMT、記号モデル検査への貢献と、それらを生物システム、コンピュータのオペレーティングシステム、プログラミング言語、セキュリティへ応用した実績で知られています。Byron が Amazon で進めてきた自動推論の取り組みは、クラウドにおけるより高い水準の保証と、お客様向けの新機能の実現につながっています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。 質問 #  うちのチームは既存システムの保守運用が中心です。不具合対応や改善要望への対応がメインで、大きな新機能をスプリントで計画的に作っていくような仕事ではありません。研修で習ったスクラムは新規開発が前提のように見えますし、うちは割り込みも多い。 うちにはスクラムは合わないのではないでしょうか？ 回答 #  合わないのは、スクラムではなく「スクラム解説の前提」のほうです。視点を変えると、保守運用はアジャイルにとってかなり自然な環境です。ウォーターフォール文化が身に染み付いた開発チームは、「最初にすべてを決めない」という考え方に慣れるのに苦労します。一方、保守運用の世界では「最初からすべて決めない」のは“当たり前”です。  さらに言えば、保守運用が向いているのはスクラムの「仕事の管理」の側面だけではありません。スクラムが定義していない、しかしアジャイルに不可欠なもう半分——テストや設計、リリースといった“モノづくりの技術”——を鍛える場として、保守運用はおそらく最良の舞台です。本稿の後半はそこに重心を置きます。  まずは、合う合わないを拙速に結論づける前に、「新規開発と保守運用は、本当に別物なのか」から考え直してみましょう。 「新規開発」と「保守運用」は、本当に別物か #  この質問の土台には、「新規機能の開発」と「保守運用の不具合対応・改善要望対応」はまったく違う仕事だ、という感覚があります。  スクラムを前提に、まずはここを疑ってみます。以下、前者を「新規開発系」、後者を「保守系」と便宜上呼び分けます。  バックログの視点で両者を並べてみると、こうなります。 新規開発系: 作りたい機能が並ぶ → 価値やリスクで優先順位をつける → 小さく完成させて届ける → フィードバックを得て次を決める 保守系: 不具合報告や改善要望が流れ込む → 影響度や緊急度で優先順位をつける → 直して届ける → 利用者の反応や再発状況を見て次を決める  　新規かどうかにかかわらず、価値のある作業項目が流入し、それらに優先順位をつけ、小さく完成させて届け、結果を見て次を判断する。一歩引いてみると、両者は構造的には同じです。スクラムが回そうとしているループそのものを、どちらの「系」も回しています。そしてどちらのバックログも、項目が後から流れ込むことを前提にしたリストです。全件が最初に揃っているべきというリストではありません。  では、何も違わないのかというと、差はあります。ただしそれは「種類の差」ではなく「程度の差」です。 項目のサイズと独立性 : 保守系の項目は小粒で、互いに独立していることが多い。新規開発系は大きく、項目間の依存が強くなりがち 流入の予測可能性 : 保守系は突発の流入が多く、来週何をやるかを今週決めきれない。新規開発系は（保守系と比べて）計画が立てやすい ステークホルダーの期待の形 : 新規開発系には「いつ、何が出るのか」が問われ、保守系には「どれだけ早く、確実に直るのか」が問われる  これらはスプリントの長さ、ゴールの立て方、キャパシティの配分といった「運用パラメータ（第1回参照）」を変える理由にはなりますが、「スクラムをやる/やらない」を分ける理由にはなりません。同じ考え方の上で、パラメータ＝調整のしかたが違うだけです。 スクラムが定義していない「もう半分」 #  もう一歩進めます。ここまでの話は、バックログと優先順位づけ、つまりスクラムが定義する「仕事の管理」の側面でした。しかしスクラムガイドを読み返すと、気づくことがあります。 スクラムは「どう作るか」を一切定義していません。 テストをどう書くか、設計をどう保つか、どの頻度で統合しリリースするか…これらはスクラムの外にあります。  アジャイルのこの「もう半分」を担ってきたのが、XP（エクストリーム・プログラミング）に代表される構築プラクティスです。自動テスト（そしてテストを先に書いてから実装するテスト駆動開発）、リファクタリング（動きを変えずに内部構造を整えること）、継続的インテグレーション（変更を頻繁に統合し自動でビルド・テストすること）、小さなリリース、シンプルな設計。スクラムだけを導入して「スプリントごとに動くものが出てこない」「スピードが落ち続ける」と悩むチームの多くは、この半分が欠けています。管理の枠組みだけあって、その中で回すモノづくりの足腰がない状態です。 保守運用は、その「もう半分」を鍛える最良の舞台だ #  ウォーターフォール文化に染まった開発チームがアジャイルに移行するとき、最大の障害はたいてい「全部決めてから作りたい」という習慣（いや欲求）です。線表を引き、要件を固め、設計を固め、実装へ…この習慣を捨てるのに、多くのチームが何ヶ月も、ときに何年も苦しみます。  ところが保守運用の現場を見てください。  来月どんな不具合が報告されるか、誰も知りません。半年先の対応計画を精緻に立てることに意味がないことを、全員が体で知っています。つまり、 「最初にすべて決めない」状態が、意図せずすでに達成されている のです。開発チームが苦労して手放す習慣が、環境としてそもそも成立しません。  そして、ここからが本題です。保守運用の日常業務は、XPの技術プラクティスの練習問題そのものです。 自動テスト : 不具合を直すとき、「まず再現するテストを書き、それを通す」のは最も自然な手順です。直した箇所が次の改修で壊れないよう回帰テストの網を増やしていくことも、保守の現場では「当然のこと」として受け入れられます。多くの未熟なアジャイルプロジェクトで「テストはリリース間際にやればよい」という誤解（開きなおり？）が平然と通っているのとは大きな違いです。 リファクタリング : 保守系の変更は小粒です。「触ったところを少しだけきれいにして戻す」を毎回やる習慣が、大規模な作り直しをせずにコードを健全に保つ唯一の現実的な方法であり、保守運用は開発者に練習する機会を多く与えてくれます。 継続的インテグレーションと小さなリリース : 項目が独立しているため、1件ずつ統合し、1件ずつ届けられます。「小さく完成させて届ける」サイクルが短く、ビルド・テスト・デプロイの自動化に投資する動機も見返りも、新規開発より明確です。 完成の定義 （何をもって「終わった」とするかのチームの合意）: スプリントごとに何度も「完成」を経験できるので、見積り・分割・「完成とは何か」の合意といった基本動作の練習回数を、新規開発案件よりはるかに多く稼げます。検査と適応のリズムも、障害の振り返りや再発防止という形で日常業務と地続きです。  このように見ていくと、「保守運用にスクラムは合わない」のではなく、むしろ「スクラムの管理の枠組みと、XP的なモノづくりの技術の両方を身につけるなら、保守運用は良い舞台である」という見方が、十分に成り立ちます。 でも限界も知っておこう #  ただし、限界もあります。保守運用で鍛えやすいのはモノづくりの側であって、スクラムの管理の側には練習しにくいことが2つあります。 スプリントゴールで仕事を「束ねる」力 。小粒で独立した項目をこなすだけなら、ゴールは「今スプリントの分を終わらせる」に退化しがちです。バラバラの作業を1つの目的に束ねる練習は、意識しないと発生しません。 価値の優先順位を巡る判断 。「直すのが当然」の不具合が相手では、「もたらす価値に基づいて何を作り、何を作らないか優先順位をつける」という、プロダクトオーナーの筋トレの機会が乏しくなります。  ほぼアジャイル初学者ばかりのチームが、いきなり本番開発に突撃して失敗している現場を少なからず見ていると、「まず保守運用でモノづくりの技術を身につける」→「新規開発でゴールやPOの筋トレに取り組みながら開発を進める」というアプローチは、十分に検討に値すると思います。  とりわけ日本では、この「モノづくりの技術」への投資が構造的に不足しがちです。経営層の中には、アジャイルを「早い、安い」という文脈で捉えている方が少なくありません。その結果、体制の編成は単価優先になり、育成への投資が省かれ、設計からコーディング、テストに至る“モノづくり”の能力がチームとして整わなくなります。スクラムの研修は受けたが、テストの自動化もリファクタリングも誰もやったことがない——そんなチームが「スクラムを始めた」と称して本番開発に突撃する光景は、珍しくありません。責めるべきは個々のエンジニアではなく、この編成と投資の意思決定です。  もっともこの意思決定も、コスト削減の制約の下では、その場その場では合理的な選択ではあります。合理的な選択の積み重ねが望まぬ結果に行き着く——この構造は、次回からの更改案件の話でも繰り返し登場します。  私見では、これがアジャイル開発の失敗の大きな要因のひとつです。保守運用を鍛錬の舞台にする提案は、この足腰を日常業務の中で鍛え直す提案でもあります。  経営層の方に、「早い、安い」の代わりに期待していただきたいのは、「変更1件のリードタイムが縮む」「切替やリリースの事故が減る」「見積の外れ幅が狭まる」という、測れる変化です。これらは、本連載の今後の回で採り上げようかと考えています。  そしてもちろん、開発チームを「価値の創造エンジン」という目で見ていただきたい。コストセンターとして単価を削る対象ではなく、 投資して育てる対象 として。 それでも現場で困ることへの処方 #  保守運用へ適用するとして、よく起こるだろう困りごとへの対処法もいくつか挙げておきましょう。 スプリントゴールが立てられない  前述したようにゴール設定はなかなか難しいかもしれません。スプリントを回し始めて数ヶ月のチームなら、ここでいっそのこと割り切って、ムリにゴール設定せず、まず「自動テストとリファクタリングを日常の手順に組み込む」といったモノづくりの基本動作に集中してもいいんじゃないかと思います。  もちろん、「ゴール決めを禁止する」意図はありません。ゴールを「機能のまとまり」で立てようとすると詰まります。改善・削減・安定化の観点で考えると立てやすくなるでしょう。「今月のアラート件数を半減する」「この手順書を廃止できる自動化を完成させる」「問い合わせ上位3件をFAQ化して問い合わせを減らす」。これらは立派なスプリントゴールであり、前述の「束ねる力」の練習にもなります。 割り込みで計画が壊れる  まず1〜2スプリント、割り込みの件数・時間・発生元を記録し、感覚ではなく実績の比率で「計画枠」と「割り込み枠」を分けてキャパシティを設計してください。詳しい運用（記録のとり方、当番制、受付の一本化など）は、第12回あたりでまとめて扱う予定です。 そもそもスプリントという区切りが実態に合わない  割り込みが恒常的に過半を占めるようなら、スクラムにこだわらず、カンバン（スプリントを区切らず、流れで仕事を管理する手法）の併用・移行を正面から検討してください。流れてくる仕事を順に引き取り、流れの速さと詰まりを改善するカンバンは、フロー中心の現場の実態に素直に合います。  スクラムは目的ではなく手段です。「スクラムをやめる」ことは「アジャイルをやめる」ことではありません。 なぜこの質問は30年繰り返されるのか #  理由は単純で、アジャイルの解説・研修・成功事例のほとんどが「新機能を開発するチーム」を暗黙の主人公にして書かれてきたからです。読者の多数派が保守運用に携わっているにもかかわらず、教材の主人公は常に新規開発チームでした。加えて日本では、新入社員研修でウォーターフォール型の開発はしっかり教えられる一方、アジャイルはほとんど扱われません。「教材がない」状態は、キャリアの入口から始まっているのです。  だから保守運用の実践者は、世代が替わるたびに「自分たちは例外なのではないか」「新しいアプローチに触れる機会が奪われているのではないか」という同じ不安を抱きます。  しかし本稿で見たように、例外なのは現場ではなく教材の前提のほうです。「先が読めない中で、小さく完成させ、学びながら進む」というスクラムの舞台装置は整っている。そのうえ、スクラムが定義しないモノづくりの技術を鍛える練習問題が、毎日流れ込んでくる。  保守運用は アジャイルの周縁ではなく 、むしろ その足腰を作る場所 だと考えてはいかがでしょうか？ 次回: 「アップグレード案件の『現行機能保証』にどう向き合う？」