こんにちは。ラクスのフロントエンド推進課の亀ノ上です。 Webアクセシビリティは、2022年のチームの課題棚卸しで私が挙げたテーマです。その後もR&Dの取り組みとして続けてきましたが、期日のある機能開発と並べると優先順位は後ろになり、着手には至っていませんでした。 今回、エンドユーザー向けの公開画面を持つ機能の開発で、Webアクセシビリティが要件になりました。対応を進める中で作ったのは、Webアクセシビリティを向上させる仕組みではありません。「どこが直せるのかを、プロダクトに手を入れずに知る」ためのレポート作成ツールでした。 この記事は、ツールの設計判断と、AIにどこまで任せられるのかが見えたところまでの記録です。同じようにWebアクセシビリティの向上に着手できずにいる方の判断材料になればと思います！ アクセシビリティが後回しになる構造 取り組みが動き出したきっかけ プロダクトにlintを入れなかった理由 ツールの構成とAIの担当範囲 ルールの絞り込み基準 3リポジトリに回して分かった傾向 AIに改善を頼んで返ってきたコード AIが指摘を消す方向に向かう理由 次の課題はインプットの設計 今回の学びと、これから アクセシビリティが後回しになる構造 まずお伝えしたいこととして、社内で取り組みを提案してこなかったわけでも、提案が否定されたわけでもありません。工数を理由に断られるというより、やるのはいいけど機能開発が優先、となって結局稼働が取れず、未着手のままになる…というのが近い状況でした。 Webアクセシビリティは、「重要だが必須要件ではない」という位置に置かれがちです。期日のある機能開発と並べれば優先度は下がります。その判断自体は自然かもしれませんが、毎期同じ優先度となると、チームは着手しないまま次の期に入ってしまいます。 取り組みが動き出したきっかけ 要件になった機能（ AI-FAQ機能 ）は、エンドユーザー向けの公開画面を持っています。管理画面でコンテンツを作り、それを外部のエンドユーザーに公開します。ラクスのプロダクトの多くはバックオフィス業務を担う管理画面です。そこに、利用者を契約企業の担当者に限定しない公開画面が加わることになります。 Webアクセシビリティが要件になった理由は、どんな環境で使われるか分からない画面で、読み上げに対応していない、キーボードで操作できない、というような状態が、そのまま「使えない人がいる」ことにつながるからです。 要件になれば、最初にやることは現状の確認です。どの画面のどこが基準を満たしていないのかが分からなければ、直す範囲も、かかる工数も見積もれません。 注意すべき点として、Webアクセシビリティの確認はすべて自動チェックに任せられるわけではありません。自動チェックで検出できるのは一部で、残りは実際の画面を操作しながら確かめることになります。 自動チェックで分かる部分に関しては、プロダクトが違っても同じ調べ方が通用することがあります。今回の取り組みでは、その部分だけを切り出して、担当プロダクト専用にしない形で作りました。フロントエンド推進課としても、各プロダクトがWebアクセシビリティをどこまで満たしているのかを一覧で把握したいというニーズがあったためです。 作成するにあたって、プロダクトに導入するのではなく、シンプルに知るためのツールにしたい...そう考えました。プロダクトに組み込むのではなく、静的解析を社内で決めた基準に合わせて横断的に回せるようにすることで、他のプロダクトも現状を知る足がかりになります。 プロダクトにlintを入れなかった理由 Webアクセシビリティ関連のlintは、プロダクトのリポジトリに入れるのが素直なやり方かもしれませんが、今回はそうしませんでした。理由は2つあります。 ひとつは、エラーが出ても解消の仕方が分からず、負担になることです。lintを入れても、ルールの意味が伝わらなければ違反は残ります。 この懸念は、lintの置き場所を変えるだけでは解けません。外から回しても、理由が分からなければ同じことです。理由をどう伝えるかは、このあとに説明します。 もうひとつは、プロダクトのコードにライブラリを追加すること自体に判断が必要になる点です。どのルールを有効にするかの選定、ライブラリのアップデート対応、チームでの運用の取り決め。どれも必要な検討ですが、これを終えるまで着手できないとすると、また「機能開発が優先」となります。 そこで作ったのが、任意のディレクトリを指定して実行するとレポートが出力される、スタンドアロンのツールでした。ツールを落としてきて、パスを指定して回すだけです。プロダクトのコードには手を入れません。 lintはプロダクトに入れず、外から回す。この段階で優先したのは、着手のハードルを下げることでした。 ツールの構成とAIの担当範囲 処理は3つの段階に分かれています。AIが関わるのは②からです。 段階 やること AIの関与 ① 検出 Vue向けのアクセシビリティlint（eslint-plugin-vuejs-accessibility）で違反を洗い出す なし ② 説明 違反を一覧化し、なぜ引っかかったのかを書いたレポートに変換する あり ③ 改善 レポートを渡して、改善されたコードを出力させる あり（ここで詰まりました） lintの出力は「このルールに違反しています」までしか教えてくれません。なぜ違反なのかを知るには、ルールのドキュメントを都度見に行く必要があります。この確認の手間が、修正に取り掛かるまでの時間を延ばします。そこで、違反箇所とその理由を読めるレポートに変換する部分にAIを使いました。レポートにはサマリーと、ファイルごとの違反ルール・違反箇所が載っています。 ここまでは特に難しくありませんでした。ドキュメントを参照しながら書かせるだけだからです。 どのルールを対象にするかは、3つの条件で絞り込んでいます。 WCAG 2.2 適合レベルAの達成基準に対応する 静的解析で検出できる プロダクト固有の実装に依存しない 2つ目の条件が、このツールの守備範囲をそのまま決めています。フォーカスの移動順序が画面の見た目と合っているか、読み上げの順序として意味が通るか、操作に応じた状態の変化が支援技術に伝わるかは、Vueのテンプレートを構文解析するだけでは判定できません。実際のDOMとスタイルを解決したうえでの検査や、ブラウザでの操作確認が要る領域です。解析対象も <template> の中に限っていて、スクリプト側のロジックに起因する問題は見ていません。このツールで違反が検出されなくても、WCAG 2.2 の適合レベルAを満たしたことにはなりません。達成基準を満たせていないところの一部を静的解析で検出できる、という位置づけです。 ルールの絞り込み基準 採用・除外の判断は単純です。そのルールをWCAG 2.2 レベルAの達成基準と照らし合わせただけで、独自の重み付けはしていません。 基準に当てはめるだけでは決まらないルールが2つありました。 ひとつはラベルに関するルールです。ラベル要素で入力欄を囲む暗黙的な関連付けは、HTML仕様上は有効です。しかし、暗黙的な関連付けは、ブラウザと支援技術の組み合わせによっては対応されていない場合もあるので、明示的な関連付けをルールに入れています。 もうひとつは、フォーカスできる要素に role="presentation" が指定されていることを検出する no-role-presentation-on-focusable です。ARIAの仕様上、フォーカスできる要素では presentation の指定自体が無視されるため、指定しても効きません。こちらは、プラグインの推奨セットにも入っていないルールであることと、手動でのテストでカバーすることを理由に、初期の対象からは外しました。 3リポジトリに回して分かった傾向 現時点でツールを回したのは3つのリポジトリです。件数の集計はしていませんが、傾向は出ました。 違反が目立ったのは、プロダクト独自のUIコンポーネントでした。共通コンポーネント側で違反が少ないのは、そこがアクセシブルだからではなく、マークアップの実装がデザインシステム側にあって、このlintが見るプロダクトのテンプレートには現れないからです。デザインシステムを持っている組織なら、まずプロダクト独自のUIから見るのがよさそうです。 AIに改善を頼んで返ってきたコード レポートの出力までは問題なく動きました。 そのレポートをAIに渡して「アクセシビリティを改善して」と指示すると、lintのエラーが出なくなるコードが返ってきました。エラーは消えます。ただ、直してほしかった方向は違っていました。 具体例を2つ挙げます。いずれもVueのコードです。 例1： alt のない画像 < img : src = "logo" /> alt 属性がないため、スクリーンリーダーによってはファイル名などが読み上げられることがあります。AIが返してきたのは以下のコードです。 < img : src = "logo" alt = "" /> alt="" は「この画像は読み上げる必要がない」という意味を持つ書き方のひとつです。そのためlintは確かに通ります。 ただ、 alt に何を書くかは、その画像の用途と周りの文脈で決まります。ロゴのすぐ横に同じ内容のテキストが置かれているなら、二重に読み上げさせないために alt="" が適切な場合もあります。この例では、そうしたテキストがなく、画像だけが情報を担っているので、読み上げる必要があります。 < img : src = "logo" alt = "ラクス" /> 指摘を消すだけなら alt="" が最短です。ただそれを選ぶと、ロゴが伝えている情報は読み上げられなくなります。lintのエラーを消す方法は複数あり、どれを選ぶかで結果が変わります。 例2：クリックできる span 多かったのは、こちらのパターンです。元のコードはこうでした。 < span tabindex = "0" @click= "handleClick" > {{ text }} </ span > span はロールを持たない要素なので、支援技術に「操作できる要素」として伝わりません。キーボードイベントのリスナーもないため、EnterやSpaceで実行できない可能性があります。 AIが返してきたのは、次のコードです。 < span role = "button" tabindex = "0" @click= "handleClick" @keydown.enter.prevent= "handleClick" @keydown.space.prevent= "handleClick" > {{ text }} </ span > 指摘は消えます。ロールが付き、EnterとSpaceでも実行できるようになりました。支援技術からは操作できる状態ですが、以下のようなコードを期待していました。 < button type = "button" @click= "handleClick" > {{ text }} </ button > button を使えば、ロールもフォーカスもキーボード操作も標準で付いてきます。AIが出したコードは、 button が最初から持っているものを属性とイベントハンドラで組み立て直したものです。差が出るのは動く・動かないではなく、以後そのコードを触る人が同じ組み立てを維持できるかどうかです。 AIが提案したコードは、目視で確認して判定しています。多かったのは、セマンティックな要素を検討してほしい場面で、属性の追加で対応されてしまうパターンでした。 2つの例は性質が違います。例1では読み上げるべき情報が失われています。例2のほうは、主要な操作自体はできるようになっています。共通しているのは、lintのエラーを消す方法が複数あるなかで、元のコードを大きく変えない方法が選ばれたことです。指摘を消すことが目的になると、この選び方になるのだと思います。 AIが指摘を消す方向に向かう理由 原因は2つあると考えています。ひとつは検証のできない仮説ですが、もうひとつは今回の作りから直接たどれるものです。 仮説のほうは、AIが学習しているコードの側に原因があるのではないかと考えています。世の中にはアクセシブルではないコードが溢れていて、だからこそAIはそれらのコードをアウトプットとして出してくる。 span にロールを付けて操作できるようにしたコードは、実際のWebでも見かけます。ただ、モデルがそのコードを選んだ理由が学習データの偏りにあるのか、元のコードとの差分を小さくしようとした結果なのかは、外からは切り分けられません。 直接たどれるほうの原因は、こちらが渡している情報です。レポートに入っているのは、引っかかった箇所のコードと、その理由だけです。そのUIが何をするコンポーネントなのか、周りのコードとどう関係しているのかは入っていません。 alt の例がそのまま当てはまります。その画像がロゴなのか、本文の理解に必要な図なのか、単なる飾りなのかは、ファイル名とタグだけでは決まりません。文脈を見ないと決められない判断を、文脈なしで求めていました。代替テキストに何を書くかは、そのコンテンツを作った人が何を伝えたいかで決まります。そこはAIには判断できません。違反箇所のコードとlintの結果だけでは、その材料がありません。 これはWebアクセシビリティに限った話ではありません。静的解析の指摘をAIに直させるとき、渡しているのが「違反したルール」だけであれば、指摘を消すことが目的になります。検査が通ることと品質が上がることは別です。AIの出力がどちらに寄るかは、違反の条件だけを渡すのか、そのコードが何をするためのものかまで渡すのかで変わります。 次の課題はインプットの設計 ここから先は、まだ結果が出ていません。現時点の仮説は2つあります。 セマンティックな要素を使うことを優先させる WAI-ARIAの仕様を確認させる どちらも、属性で辻褄を合わせる方向に行かせないための指示です。ただ、指示文に書くだけで足りるのか、参照する資料まで渡す必要があるのかは、まだ検証していません。 ARIA Authoring Practices Guide（APG）のような、「このパターンはこうマークアップする」という指針が示されたガイドを参照させる案もありますが、これも着手前です。毎回ガイド全体を読ませるのは非効率なので、lintのルールに関連するAPGの箇所をリファレンスとして持たせる形も考えられそうです。 AIに任せられる範囲は、渡せる情報をどこまで設計できるかで決まります。今回の設計では、lintによる検出と、AIによる説明までは成立しました。改善まで任せようとすると、同じ情報だけでは足りませんでした。 今回の学びと、これから 今回の取り組みで得た学びのひとつは、AIによるWebアクセシビリティ向上の自動化は難しい、ということです。最終的に人間のレビューは必要で、だからこそ適切に判断できるように、Webアクセシビリティの知識をこれからもつけていきたいと考えています。 AIに任せる範囲を広げるほど、出てきたものを正しいと判断できる人が必要になります。Webアクセシビリティのように、ルールを通すことと、目的を果たすことがずれやすい領域では、その差が出やすくなります。 次は他プロダクトへの横展開ですが、その前にやることがあります。広げる前に、まず担当プロダクトのチームに展開して、誰でも対応できる運用にできるかを確かめます。ここが目の前のハードルです。 最後に、この記事の持ち帰りを4つに整理します。 Webアクセシビリティの向上に着手できていないなら、コードを直すところから始める必要はないかもしれません。まず「どこに問題がありそうかを知る」ところからなら、小さく始められます。 現状把握を始める段階なら、プロダクトにlintを組み込む判断を待たず、外から実行する方法も選べます。 デザインシステムを持っているなら、静的解析の指摘はプロダクト独自のUIに集まりやすくなります。探し始める場所の目安になるかもしれません。 検出はlintに、違反理由の説明はAIに任せられました。改善まで任せるなら、何を渡すかを設計する仕事が人間側に残ります。 直接コードの修正ができなくても、Webアクセシビリティを前に進めるアプローチはいろいろあると思います。思ったように取り組めずにいる方にとって、何かしらの参考になれば幸いです。

本ブログは 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 の 中島 章博 が翻訳しました。

こんにちは、エンジニアの澤田です。 前回の記事 では、Rust で RgbColor 構造体を使って演算子オーバーロードをやってみましたが、今回はその RgbColor を使ってグラデーションを表現するイテレータを作ってみたいと思います。 私はイテレータを普段の業務であまり意識せずに使っていましたが、イテレータのインターフェースを実装することで理解を深めたいと思い、試してみました！ ※rustc と cargo はバージョン 1.97.1、edition 2024 を使用しています。 イテレータとは イテレータを一言でいうと、 次の要素を1つずつ返してくれるもの です。 配列のように