こんにちは、データサイエンスプロダクトグループの清田です。 2026年6月8日から12日にかけて、群馬県高崎市のGメッセ群馬で開催された 人工知能学会全国大会（JSAI2026） に参加してきました。私たちはこの大会で、 オーガナイズドセッション「不動産とAI」 （OS-27）を企画・開催しました。今年はこのセッションにとって特別な年で、「不動産とAI」という研究コミュニティが10周年の節目を迎えました。 本記事では、セッションの内容をダイジェストでお伝えするとともに、その10年の裏側にあった LIFULL HOME'Sデータセットの提供 という取り組み、そして私たちがこれからの10年をどう描こうとしているのかを、あわせてご紹介します。 JSAI2026の会場となったGメッセ群馬 「不動産とAI」オーガナイズドセッションとは 10年の裏側にあった、LIFULL HOME'Sデータセット この10年の歩み ―「価格を当てる」から「価値を捉える」へ 黎明期（2016–2017） 学際展開期（2018鹿児島・2019新潟） 進化期（2020・2021オンライン） 体系化・生成AI期（2022京都〜2025大阪、そして2026群馬） セッションダイジェスト テーマ1：AIが機能する「情報基盤」を問う テーマ2：予測モデルを、AI自身が高度化する テーマ3：感性・意味・物語を、価値にする これからの10年 ― 価値の多元化 おわりに 「不動産とAI」オーガナイズドセッションとは 「不動産とAI」は、人工知能学会全国大会で毎年開催してきたオーガナイズドセッションです。今年は6月10日（水）午前中に開催し、9件の研究発表と総合討論を行いました。会場（K会場）は終始盛況で、オンラインからの参加者や、同じ時間に隣の会場で開催されていた GeoAI（地理空間情報とAI）のセッション からの合流もあり、活発な議論が交わされました。 sites.google.com オーガナイザは、橋本武彦さん（GA technologies）、私 清田、山崎俊彦先生（東京大学）、諏訪博彦先生（奈良先端科学技術大学院大学）、清水千弘先生（一橋大学）、吉原勝己さん（スペースRデザイン／NPO法人福岡ビルストック研究会）の6名です。不動産の事業者、AI・情報学の研究者、経済学者、まちづくりの実践者と、立場の異なるメンバーが集まっているのが、このコミュニティの特徴です。 ここで言う「不動産とAI」は、賃料や価格の予測だけを指すのではありません。国内では「不動産テック」、海外では PropTech（プロップテック）と呼ばれる広い領域――取引仲介、不動産×金融、物件管理、建築・建設、スマートビル、さらには街づくりや人の流れまで――を視野に入れています。 「不動産とAI」セッション冒頭の趣旨説明のスライドは、こちらで公開しています。 speakerdeck.com 10年の裏側にあった、LIFULL HOME'Sデータセット 実は今回は、コミュニティの10周年であると同時に、研究の土台の一つとなってきた LIFULL HOME'Sデータセット の提供開始からも、ちょうど10年の節目にあたります。 このデータセットは、2015年11月に、国立情報学研究所（NII）の 情報学研究データリポジトリ（IDR） を通じて、研究者の皆さまに提供を開始したものです。物件情報や間取り画像といった、それまで研究の世界ではなかなか手に入らなかった不動産データを、産学連携の形でオープンにしていく――この取り組みが、不動産分野の機械学習・AI研究が立ち上がる一つのきっかけになりました。 www.lifull.blog 「不動産とAI」コミュニティが2016年に始まったのも、こうしてデータが流通し始め、研究テーマが具体的に語れるようになってきたことと無関係ではありません。データを提供する側だったLIFULLにとって、この10年は「提供したデータが、どんな研究を生み、社会にどう還っていくのか」を見届ける10年でもありました。 この10年の歩み ―「価格を当てる」から「価値を捉える」へ セッションの趣旨説明では、この10年を一言でまとめるなら「価格をどう当てるかという問いから、価値をどう捉えるかという問いへ」の深化だった、とお話ししました。 かつての不動産AIは、ヘドニック回帰に代表されるように、価格という一点の数字をいかに精度よく当てるかが中心でした。それが、不動産物件の感性価値・本来価値・長期価値といった多面的な価値をどう捉え、社会と共有するかへと、関心が移ってきています。不動産は、あらゆる財の中でも最も価値の測定が難しい対象です。その難しさに、私たちは10年かけて少しずつ近づいてきました。 歩みは大きく4つの時期に分けられます。 黎明期（2016–2017） データのオープン化。LIFULL HOME'Sデータセットの提供開始、FIT2016（富山）・FIT2017（東大）、そして2017年名古屋からの人工知能学会全国大会セッション開始。 FIT2016 第15回情報科学技術フォーラム FIT2017 第16回情報科学技術フォーラム sites.google.com www.lifull.blog 学際展開期（2018鹿児島・2019新潟） 経済学・建築学・都市学・情報学が交わる場へ。間取りのグラフ化や賃料予測など、テーマが一気に多様化。国際会議ワークショップの開催にもつながる。 sites.google.com sites.google.com sites.google.com sites.google.com 進化期（2020・2021オンライン） 山崎先生の「 魅力工学 」が合流し、感性のデータ化が本格化。情報の非対称性や、減価償却ルールによる建物価値の毀損といった本質的な問いへ。 sites.google.com sites.google.com 体系化・生成AI期（2022京都〜2025大阪、そして2026群馬） LIFULL HOME'Sデータセットの研究利用実績は150件を超え、生成AIが新しい潮流に。 sites.google.com sites.google.com sites.google.com www.lifull.blog sites.google.com ここに述べたように、富山から始まり、名古屋・鹿児島・新潟、オンライン、京都・熊本・浜松・大阪、そして群馬へ。 毎年場所を変えながら、議論を積み重ねてきました。 セッションダイジェスト 今年の9件の発表は、大きく3つのテーマに束ねられます。 テーマ1：AIが機能する「情報基盤」を問う 生成AIの性能は飛躍的に上がりました。しかし現場では、AIの性能よりも前に、そもそもAIが使えるデータが整っていないという壁にぶつかります。 合同会社アキューズの齋藤孝春さんは、宅地建物取引士でありAIエンジニアでもある立場から、重要事項説明書（重説）作成の現場を報告されました。重説に必要な情報は、法務局・区役所の複数部署・水道局・ガス事業者……と7〜10もの窓口に分散し、統合的に照会する仕組みがありません。齋藤さんの「真の障壁はAIの性能不足ではなく、情報基盤の構造的課題だ」という指摘は、セッション全体を貫く論点になりました。総合討論やSlackでの質疑では、「行政情報が情報化されても、私人間の文書（境界確認書など）が残るため、AIが担えるのは作成業務の7割程度ではないか」という、現場ならではの踏み込んだ議論にも発展しました。 [3K1-OS-27a-02] 重要事項説明書作成におけるAI活用の前提条件 情報基盤の課題と提言 〇齋藤 孝春 (合同会社アキューズ) 日本取引所グループの田中麻由梨さん・土井惟成さんは、J-REITの有価証券報告書から投資物件情報を構造化する手法を発表されました。投資法人ごとにバラバラな表形式を、共通のプロンプトとチャンク化で頑健に読み取り、主要項目でF1スコア0.977という高い精度を達成。開示文書という「半構造データ」をAIの入力に変える、実務に直結する研究です。 [3K1-OS-27a-05] 多様な表形式のデータに対してロバストなJ-REIT投資物件情報の構造化手法の提案 〇田中 麻由梨、土井 惟成 (株式会社日本取引所グループ) 東京大学の増田俊太郎さん・山崎先生、エムディーの平井樹さんのグループは、衛星画像・ストリートビュー・道路名といった公開データから、大規模マルチモーダルモデルで意味特徴を抽出し、道路の交通量を推定する研究を発表されました。観測コストが高く幹線道路に偏りがちな交通量データを、公開データで補うという発想で、店舗の商圏分析にもつながります。 [3K2-OS-27b-04] マルチモーダル地理意味特徴に対するタスク考慮型クラスタリングによる交通量推定 〇増田 俊太郎1、平井 樹2、山崎 俊彦1 (1. 東京大学大学院、2. エムディー株式会社) テーマ2：予測モデルを、AI自身が高度化する 東京大学の髙辻優太さん・山崎先生、estieの岩成 達哉さんらのグループは、賃料予測モデルの改善プロセスそのものをLLMに自動で反復させるフレームワークを発表されました。「誤差を分析し、改善案を出し、コードを実装し、評価する」というデータサイエンティストの試行錯誤をGPTが代行し、全国の賃貸データでベースラインから統計的に有意な精度向上を実現しています。 [3K1-OS-27a-04] 大規模言語モデルによる多角的誤差分析に基づいた不動産賃料予測手法の自動改善 〇髙辻 優太1、岩成 達哉2、勝田 良介2、増田 俊太郎1、易 聖舟1、山﨑 俊彦1 (1. 東京大学、2. 株式会社estie) 東京大学の玉真永棋さんらは、金利上昇下でも高騰を続ける東京の住宅市場を、エージェントベースモデル（ABM）で再現しました。世帯や投資家といった異質な主体の「トレンド追随（群集行動）」を組み込むことで、ファンダメンタルズだけでは説明できない価格の増幅メカニズムを分析しています。 [3K1-OS-27a-03] 住宅市場ABMにおけるハーディングモデルの拡張と価格増幅メカニズム分析 〇玉真 永棋、藤井 秀樹 (東京大学大学院) テーマ3：感性・意味・物語を、価値にする 東京科学大学の沖拓弥さんらは、オフィスビルの外観の印象を、約2万棟の画像と20万件のアンケートから定量化し、視覚言語モデルを使って「どんな外観要素が好印象につながるか」まで分析されました。狙いは、新しく大きい建物が高評価という当たり前の結論を超えて、古く小さな既存ストックの魅力を引き出すことにあります。 [3K1-OS-27a-06] 賃貸オフィスビルの外観の印象評価構造 藤田 晋太朗1、〇沖 拓弥1、松尾 和史2、今関 豊和2 (1. 東京科学大学、2. オフィスビル総合研究所) ニュージャージー工科大学の楢原太郎さんは、間取りの「住み心地」をAIがどこまで読めるかを検証されました。GPTは開放感や現代性といった視覚的印象には強い一方、動線やプライバシーのような「部屋同士のつながり」の理解にはまだ弱い――AIの能力の境界を、丁寧に示す研究です。 [3K2-OS-27b-01] 人間と大規模言語モデルによる不動産間取り評価の比較分析 ―視覚的印象評価と構造理解の差異― 〇楢原 太郎1、山崎 俊彦2 (1. ニュージャージー工科大学、2. 東京大学) そして今年特に話題を集めたのが、 「ビル格（Building Personality）」 という考え方でした。樅山拓大さん（マレーシアAPU）と吉原勝己さん（吉原住宅）は、建物を「数字で測る対象」から「意味を語り、判断する主体」へと捉え直し、建物の歴史・文化・関係者の想いといった質的情報をLLMで構造化する枠組みを提案されました。舞台となったのは、築67年で民間のRC集合住宅として日本初の登録有形文化財となった福岡の「冷泉荘」です。 [3K2-OS-27b-02] ビル格（Building Personality）：人格を持つ不動産がもたらす新領域 生成AIによる建物の主体化と既存建築ストックの価値再定義 〇樅山 拓大1、吉原 勝己2 (1. Asia Pacific University of Technology & Innovation (APU)、2. 吉原住宅有限会社) LIFULL HOME'S PRESS: ビンテージマンションを多様な個性が集まるミュージアムに。福岡「冷泉荘」を訪問 www.space-r.net 樅山さん・吉原さんによるご発表の様子 私（清田）と麗澤大学の学生2名（豊田智康さん・長嶋一樹さん）は、この続編として、ビル格を起点に生成AIで動画と音楽をつくり、不動産リブランディングに使えるかを実験しました。分かったのは、「らしさ」の源泉は築年数や外観といったスペックではなく、入居者・文化・歴史といった一次情報にあること。そして生成AIの価値は、出力そのものより、目的設計と人による編集（Human-in-the-loop）にあること、でした。 [3K2-OS-27b-03] 建物人格を媒介とした生成AIによる不動産ブランディング 冷泉荘におけるマルチモーダル生成実験の報告 〇清田 陽司、豊田 智康、長嶋 一樹 (麗澤大学) speakerdeck.com 麗澤大学の学生2名による動画・音楽生成の実践報告 これからの10年 ― 価値の多元化 総合討論では、次の10年に向けた三つの問いを掲げました。すなわち、①解決すべき課題（研究・応用の障壁）は何か、②必要なデータとは何か、③求められる研究は何か、です。 私からは、これからの不動産の価値が「多元化」していくという見立てをお話ししました。鍵となるのは3つの価値軸です。 感性価値：街の音・光・緑・人の流れを可視化する 本来価値：建物の性能や管理の履歴、長期リスクをふまえて評価する（AIやドローンによる点検が支える） 長期価値：10年・20年・30年先を、街の文脈ごとシミュレーションする これらは制度としても、AI点検の標準化、性能履歴に基づく本来価値の評価、ウェルビーイングや街の魅力の都市評価への組み込み……といった形で社会に根づいていくと考えています。世界の不動産テック市場も、2025年の約450億ドルから2036年には約2500億ドルへと、大きな成長が見込まれる領域です。 総合討論では、「過去の情報で学習するLLMで、創造的な未来の街を描けるのか」（防災の観点から）、「自治体ごとにデータがバラバラなのは、実は民間にも原因があるのではないか」、「LLMのおかげで自然言語のデータも資産にできるようになった」といった、刺激的な論点が次々と出ました。国土交通省・内閣官房が2026年に立ち上げた「ジオAI研究会」の紹介もあり、GeoAIコミュニティとの連携、そして何より研究と現場の接続が、次の10年の大きなテーマになりそうです。 www.mlit.go.jp おわりに 10年前、私たちはデータを提供する側として、この分野のスタートラインに立ちました。10年が経ち、データは多くの研究を生み、生成AIという新しい力も加わって、「価格」から「価値」へと問いは深まってきました。次の10年は、その多元的な価値を、研究者だけでなく現場の方々と一緒に、社会と共有できる形にしていく10年にしたいと思っています。 LIFULLは、これからもデータと研究を通じて、「あらゆるLIFEを、FULLに。」という思いのもと、不動産とAIの未来づくりに取り組んでいきます。 LIFULLでは、データサイエンス・AIに取り組む仲間を募集しています。ご興味のある方は採用ページをご覧ください。 hrmos.co

融資システムのテストを担当すると、「一般的なシステムテストと同じ考え方でよいのか」「どの機能まで細かく確認すればよいのか」と迷いやすいものです。 特に融資業務は、申込情報を登録して終わるものではなく、 審査・承認・契約・融資実行・返済まで複数の処理が連続してつながっています 。 個人融資を扱うシステムでも、商品や申込内容に応じたワークフロー、自動審査、信用情報機関への照会、勘定系システムとの連携など、多くの機能が組み合わされています。 そのため、個々の画面が正常に動くことだけを確認しても、融資システム全体の品質を十分に確かめたことにはなりません。 融資金額や金利、返済額、審査結果などに誤りがあれば、顧客や金融機関の業務へ大きな影響を与える可能性があります。 金融機関のシステムでは、システムの停止や誤作動、不正使用などによって顧客や金融機関が損失を被るリスクも考慮する必要があります。 そこで今回は、 融資システムで押さえたいテスト観点とテストケースの作り方を、業務の流れとリスクの両面から整理しました！ 融資業務に不慣れな場合でも、どこから確認すればよいか判断できるよう、実務に落とし込みやすい順番で解説します。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テストの種類について詳しい内容はこちら▼ 【保存版】テストの目的別タイプ一覧 まず押さえたい！融資システムのテストは「業務の流れ」から考える 融資システムのテストを考えるとき、最初から画面一覧や機能一覧を見てテストケースを書き始めると、重要な確認が抜けることがあります。 先に整理したいのは、 融資案件がどのような業務を通り、どのデータやシステムと関係するのか という全体像です。 たとえば個人融資では、申込内容に応じて審査を行い、信用情報や行内情報を取得し、条件を判定したうえで後続の手続きへ進む仕組みがあります。 融資実行後も、残高管理、条件変更、保証料計算、入出金、完済などの処理が続くケースがあります。 つまり、テスト対象を「申込画面」「審査画面」といった単位だけで捉えると、画面と画面の間で起こるデータ不整合や誤った状態遷移を見落としかねません。 業務フローを軸に機能を並べ、その流れが途中で崩れないか確認すること が、融資システムにおけるテスト設計の基本になります。 融資申込から返済までの流れをつかめば、テストの抜け漏れを減らせる！ まず、対象となる融資商品の業務フローを整理します。 一般的には、申込受付から審査、承認、契約、融資実行へ進み、実行後は返済や残高管理、条件変更などの処理につながります。 企業向けの融資管理システムでは、申込・契約登録・実行・請求・回収・延滞債権管理・返済条件変更などを一連の業務として扱う製品もあります。 ここで大切なのは、 各工程を独立した機能として見るのではなく、前後の工程とのつながりを見ること です。 たとえば、申込時に入力した融資希望額や顧客情報が審査処理へ正しく渡っているか、承認された案件だけが契約へ進めるか、契約済みの内容と実行時の条件が一致しているかを確認します。 業務フロー図だけでなく、状態遷移図、要件定義書、画面一覧、帳票一覧、外部インターフェース一覧なども組み合わせると、確認対象を洗い出しやすくなります。 商品によって業務ルールは異なるため、住宅ローンやカードローン、事業性融資などを同じテストケースで一律に扱わず、 対象商品のルールを起点にテスト範囲を決めること が重要です。 単体・結合・総合・受け入れテストの役割を整理しよう！ 融資システムでは、テスト工程ごとに確認する目的を分けると、同じ確認を繰り返すだけのテストになりにくくなります。 単体テストでは、金額計算や条件分岐、入力チェック、エラー処理など、個々のプログラムや機能が想定通りに動くかを確認します。 結合テストでは、画面、API（アプリケーション・プログラミング・インターフェース）、データベース、バッチ、外部サービスなどを組み合わせたときに、情報が正しく受け渡されるかを確認します。 システムテストでは、統合されたシステム全体が要求された動作を満たすかを確認し、受け入れテストでは業務上必要な処理を実際に遂行できるかを確かめます。 融資システムであれば、総合的なテストでは 申込から審査、契約、融資実行までを一つの業務シナリオとして通す視点 が重要です。 受け入れテストでは、単に仕様書通りかを見るだけでなく、担当者が現実の業務手順で問題なく処理できるか、必要な情報を確認できるかまで検証します。 工程ごとに「何を確認するか」だけでなく、 この工程でどのリスクを取り除くのか を決めておくと、テスト目的が明確になります。 テスト項目を増やす前に「障害が起きたら何が困るか」を考えよう！ テストケースを増やせば品質が比例して高くなるとは限りません。 システムが複雑になるほど、考えられる入力や条件の組み合わせも増えるため、すべてを同じ深さで確認するのは現実的ではありません。 そこで役立つのが、 障害が発生する可能性と、発生した場合の影響を踏まえて優先順位を付けるリスクベースの考え方 です。 融資システムなら、融資額や金利、返済額など顧客の金銭に直接関係する処理、審査・承認など融資判断を左右する処理は、優先度を高く設定しやすい領域です。 「金利が誤って計算される」「否決案件が実行される」「同じ融資が二重実行される」「障害復旧後に同じ処理が再実行される」といった 起きてはいけない事象から逆算する方法 も有効です。 金融システムでは、停止や誤作動だけでなく、不正利用や重要情報への不正アクセスもシステムリスクになります。 限られた期間で品質を確保するには、すべてを均等に確認するのではなく、 業務への影響が大きい部分ほどテストを厚くする設計 が求められます。 ここは外せない！融資システムで確認したい重要テスト観点 融資システムには、一般的な業務システムでも必要になる入力チェックや画面遷移に加え、金融業務ならではのテスト観点があります。 特に重要なのが、 金額・金利・返済、審査条件、案件ステータス、権限、外部システム連携、日付処理 です。 個人融資の審査システムでも、自動審査、商品規定や審査規定による判定、信用情報機関への照会、勘定系やWeb申込システムとの外部連携など、複数の要素が組み合わされています。 実行後の管理では、残高や保証料、条件変更、入出金、完済などの処理も発生します。 それぞれを個別に確認するだけでなく、ある処理の結果が後続処理へ正しく反映されるかを見る必要があります。 ここからは、融資システムのテストケースを設計するときに優先して確認したい観点を整理します。 金額・金利・返済計算は「1円のズレ」まで確認する！ 融資システムで特に慎重に確認したいのが、 融資金額・金利・利息・返済額・残高などの金額計算 です。 画面に表示された結果だけでなく、内部データ、帳票、外部システムへ連携される値まで一致しているかを確認します。 金額条件には、最低融資額や最高融資額、融資限度額などの境界が設定される場合があるため、境界値そのものだけでなく、その直前と直後もテストすると不具合を見つけやすくなります。 金利計算では、小数点以下の扱いや端数処理、切り上げ、切り捨て、四捨五入などのルールも確認対象です。 返済についても、通常の約定返済だけでなく、一部繰上返済、全額繰上返済、返済条件変更などを考慮します。 融資管理システムには、元金均等・元利均等・期限一括といった返済方法や、固定金利・変動金利、一部・全額の繰上返済を扱うものもあります。 計算結果だけでなく、その結果が後続処理へ正しく引き継がれるところまで確認すること がポイントです。 審査・承認は「条件の組み合わせ」と「境界」を重点的に確認する！ 融資審査では、一つの入力値だけで結果が決まるとは限りません。 商品条件や申込内容、行内情報、信用情報など、複数の情報を使って審査処理を行うシステムがあります。 そのため、テストケースでは どの条件によって審査結果が切り替わるのか を明確にする必要があります。 承認されるケースだけではなく、否決、保留、追加確認など、仕様上存在する結果を一通り通せるデータを準備します。 条件の組み合わせが多い場合は、すべての組み合わせを機械的に作るのではなく、判定結果が変化する条件を優先します。 たとえば限度額や対象年齢、申込期間などに境界がある場合は、条件を一つだけ変えて結果の変化を見ることで、判定ロジックの誤りを発見しやすくなります。 自動審査のあとに担当者の確認や承認を挟む仕組みでは、自動判定そのものだけでなく、 判定結果が正しい担当者へ渡り、その後の操作が適切に制御されるか まで確認しましょう。 ステータスと業務フローは「進めるケース」と「進めないケース」の両方を見る！ 融資案件には、申込受付、審査中、承認、否決、契約済、実行済、完済など、処理状況に応じた状態があります。 テストでは、正しい順番で状態が変わることに加えて、 本来は許可されない順番で処理できないこと も確認します。 たとえば、審査が終わっていない案件を契約済みにできないことや、否決された案件をそのまま融資実行できないことなどが確認例です。 正常系だけを実行していると、このような禁止ルートの不具合を見落としやすくなります。 さらに、現実の業務では取消、差戻し、再申請、再審査、条件変更など、一直線に進まないケースも発生します。 複数の担当者が同じ案件を操作できるシステムでは、同時操作によって更新内容が失われないか、承認や融資実行が重複しないかも確認したいポイントです。 「正しく進めること」と「誤った状態では進めないこと」をセットでテストする と、状態遷移に関する抜け漏れを抑えやすくなります。 権限・本人確認・セキュリティは「見えてはいけない・できてはいけない」まで確認する！ 融資業務では、顧客情報や審査情報など重要な情報を扱うため、権限制御やセキュリティも重要なテスト対象です。 担当者、承認者、管理者など役割が分かれている場合は、それぞれの利用者が参照・登録・変更・承認できる範囲を確認します。 画面上でボタンが非表示になっているだけではなく、URLを直接指定した場合やAPIを直接呼び出した場合にも、権限のない処理を実行できないことが重要です。 本人確認が必要な業務では、確認が完了していない状態で契約や融資実行などの後続処理へ進めないかも確認します。 金融機関では、システムの不正使用や重要情報への不正アクセス、漏えいなども重大なシステムリスクとして扱われます。 金融情報システムの安全対策に関する基準も継続的に更新されており、2026年3月には第14版が公開されています。 機能が正常に動くかだけではなく、 見えてはいけない情報が見えないこと、実行してはいけない操作が実行できないこと もテスト観点として組み込みましょう。 外部連携・バッチ・日付処理は「止まったとき」までテストする！ 融資システムは単独で完結せず、複数のシステムと連携するケースがあります。 個人融資の審査領域では、勘定系、情報系システム、Web申込システム、担保評価システム、個人信用情報機関などとの連携が考えられます。 そのため、正常にデータが返る場合だけでなく、 タイムアウト、通信切断、エラー応答、応答遅延などが発生した場合 も確認します。 通信エラー後に自動で再実行する仕組みでは、同じ申込や融資実行が二重登録されないことも重要です。 また、返済日や利息計算、期日管理などでは日付条件が結果に影響するため、月末、年末、年度末、うるう年、休日などのケースも検討します。 日次や月次のバッチ処理が途中で停止した場合は、復旧後にどこから再開するのか、処理済みデータが再処理されないかを確認します。 外部システムやバッチが正常に動く前提だけでテストせず、「止まる・遅れる・途中で失敗する」状況まで想定すること が重要です。 抜け漏れとムダを減らす！実践的なテストケースの作り方 重要なテスト観点を把握しても、そのまま項目を並べるだけではケース数が膨らみやすくなります。 融資システムでは商品、顧客属性、金額、審査条件、権限、状態など多くの条件が組み合わさるため、すべての組み合わせをテストしようとすると現実的な件数に収まらないことがあります。 テスト設計では、 何を確認するかと同時に、何を優先して確認するかを決めること が重要です。 リスクの高い機能や条件を厚く確認し、影響の小さい部分まで同じ粒度でテストしないよう濃淡を付けます。 また、ケース作成と並行してテストデータや証跡の残し方まで考えておけば、テスト実施段階での手戻りも抑えやすくなります。 ここでは、限られた工数の中でテストの抜け漏れとムダを減らすための具体的な方法を整理します。 まず「業務リスク×機能」の一覧を作って優先順位を付ける！ 最初に、対象機能とその機能で障害が発生した場合の影響をセットで整理します。 たとえば「融資実行」という機能だけを書くのではなく、「誤った金額で実行される」「同一案件が二重実行される」「未承認案件が実行される」といった問題まで具体化します。 そのうえで、顧客資産への影響、業務停止の有無、情報漏えい、復旧の難しさなどを基準に優先順位を付けます。 リスクベーステストは、 リスクの種類やレベルをもとにテスト活動やリソースの優先順位を決める考え方 です。 高リスクと判断した領域では、正常系だけでなく、異常系、境界値、組み合わせ、障害復旧などまで確認範囲を広げます。 反対に影響が限定的な機能では、重要な正常系を中心にするなど、テストの深さを調整します。 この整理を残しておけば、レビュー時にも「なぜこの機能を重点的に確認するのか」を説明でき、 ケース数ではなくリスクに基づいてテスト計画の妥当性を示しやすくなります 。 正常系だけで安心しない！6つの切り口でテストケースを広げる テストケースを考えるときは、正常系だけで終わらせず、 正常系・異常系・境界値・組み合わせ・状態遷移と権限・障害と復旧 という切り口から確認します。 正常系では、想定された申込内容と正しい業務手順によって、融資処理を最後まで完了できるかを確認します。 異常系では、必須項目不足、不正な入力、外部連携エラーなどに対して適切なエラー処理が行われるかを見ます。 境界値では、融資限度額や年齢、期間など、判定結果が切り替わる値の直前・境界そのもの・直後を確認します。 組み合わせでは、商品、顧客属性、申込条件、審査条件などを組み合わせたときに、単独条件では発生しない不具合がないかを確認します。 状態遷移と権限では、案件の状態や利用者の役割によって操作可否が適切に変わるかを検証します。 障害と復旧では、処理中断や通信失敗後に データ不整合、処理漏れ、二重処理が残らないこと まで確認すると、実運用に近いテストになります。 テストデータは「ケースを書いたあと」ではなく設計段階で準備する！ テストケースが完成してからデータを用意しようとすると、「必要な条件の顧客を作れない」「審査結果を狙った状態にできない」といった問題が起こりやすくなります。 そのため、 テストケースを設計する段階で必要なデータ条件も同時に決めること が大切です。 たとえば正常に承認されるデータだけでなく、限度額ぎりぎり、審査条件を一つだけ満たさない、延滞状態、返済条件変更後など、確認したい結果を再現できるデータを整理します。 前工程で作った案件を後工程でも利用する場合は、どのデータが申込中で、どのデータが承認済みなのかといった状態管理も必要です。 同じデータを複数人が使うと、途中で状態が変わって再現できなくなることもあるため、利用ルールを決めておくとテストが安定します。 また、個人情報や金融情報を扱うシステムでは、本番情報を安易にコピーするのではなく、プロジェクトのセキュリティルールに沿ったデータ準備が欠かせません。 何度実行しても同じ条件を再現できるデータを用意しておくこと は、再テストや障害解析の効率向上にもつながります。 テスト結果は「合格・不合格」だけでなく、判断できる証跡を残す！ テストを実行した結果として「合格」と記録するだけでは、あとから同じ結果を確認することが難しくなります。 実施日時、使用したテストデータ、操作内容、期待結果、実際の結果などを追跡できる形で残しておくと、レビューや障害調査が進めやすくなります。 必要に応じて画面キャプチャ、APIの応答内容、ログ、帳票などを保存し、 第三者が見ても期待結果と実際の結果を比較できる状態 にします。 金融系システムのテストでは、操作ログや画面キャプチャなど大量の証跡を扱うケースがあり、証跡取得自体が大きな作業になることもあります。 すべての操作で大量の証跡を残せばよいわけではなく、プロジェクトのルールや確認目的に合わせて取得対象を決めることが重要です。 不具合が見つかった場合は、入力データや操作順序、ログなどから同じ現象を再現できる情報を残します。 結果を残す目的は資料を増やすことではなく、あとから正しく判断・再現できるようにすること と考えると、必要な証跡を選びやすくなります。 自動化は「全部やる」のではなく、繰り返すテストから始める！ 融資システムのテスト工数を減らす方法として、自動化を検討するケースもあります。 ただし、最初からすべてのテストを自動化しようとすると、シナリオ作成や保守に時間がかかり、かえって負担が増えることがあります。 まずは、 同じ操作を何度も繰り返す回帰テストや、期待結果を機械的に判定しやすい処理 から候補を選ぶ方法が現実的です。 金額計算の確認、APIテスト、データの比較、同一シナリオの繰り返し実行などは、自動化を検討しやすい領域です。 実際の融資管理システム開発でも、手作業で行っていたテストに自動化を導入し、証跡取得や結果確認の負担を軽減した事例があります。 一方で、担当者による業務判断や画面の使いやすさなど、人が確認したほうが適切な項目まで無理に自動化する必要はありません。 金融系の開発・テスト環境ではネットワークやセキュリティ上の制約も考えられるため、導入前に実行環境やツールの保守方法まで確認します。 自動化率の高さではなく、繰り返し工数や確認負荷をどれだけ減らせるかを基準に対象を選ぶこと が重要です。 まとめ｜融資システムのテストは「機能」ではなく「業務リスク」から組み立てよう！ 融資システムのテストでは、画面や機能を一つずつ確認するだけではなく、 申込・審査・契約・融資実行・返済までの業務全体をつなげて考えること が重要です。 特に、融資金額や金利、返済計算、審査条件、状態遷移、権限、外部システム連携、日付処理などは、融資業務の品質を左右しやすい確認領域です。 正常に処理できるケースだけでなく、異常値、境界値、禁止操作、通信障害、処理中断後の復旧まで対象を広げることで、本番環境で問題になりやすい不具合を見つけやすくなります。 ただし、考えられる条件をすべてテストしようとするとケース数が膨大になるため、重要度を無視した網羅は現実的ではありません。 障害が起きた場合にどのような影響が出るのかを整理し、影響の大きい領域から優先してテストを厚くすること が、品質と工数を両立するポイントです。 テストデータや証跡、自動化についても、テスト実行を始めてから考えるのではなく、設計段階から準備しておくと手戻りを抑えやすくなります。 まずは対象となる融資商品の業務フローを書き出し、それぞれの工程で「起きてはいけない事象」を整理するところから始めると、必要なテスト観点を体系的に洗い出せるようになります。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

出展の概要 会場の印象 アプトポッドブースの展示 点検・警備ソリューション メーター読み取り 四足歩行ロボット以外の連携：ドローン・ウェアラブルカメラ・サーマルカメラ 通信 リアルタイムデジタルツインソリューション 映像3Dモデル化デモ フィジカルAI 来場者の反応 まとめ こんにちは、クロスインダストリー事業部ソリューション開発グループの影山です。同事業部で製品・ソリューションの開発を担当しています。 この度、株式会社アプトポッドは、2026年7月15日（水）から17日（金）までの3日間、東京ビッグサイト東展示棟で開催された「メンテナンス・レジリエンス 2026」に出展しました。おかげさまで3日間を通して多くの方にブースへお立ち寄りいただきました。ありがとうございました。 https://mente.jma.or.jp/ 今年は、点検・警備、リアルタイムデジタルツイン、フィジカルAIといったトピックにフォーカスして展示を行いました。本記事では、それぞれについてご紹介していきたいと思います。 出展の概要 アプトポッドは産業用IoTミドルウェア「 intdash 」を提供しています。これまで自動車開発や建設機械の領域で導入いただいてきましたが、設備の点検・保全という領域でもintdashの特長を生かせると考え、さまざまなユースケースのデモや事例を展示しました。intdashはマルチモーダルなデータをリアルタイムに扱うことに長けています。カメラ映像、LiDARの点群、ロボットのROSトピック、ガスセンサーの値、既存設備のデータといった、種類も周期もばらばらな大量のデータを、時刻を揃えたままリアルタイムに集めて遠隔から扱いたい、というニーズにマッチします。 www.aptpod.co.jp 今回のデモ全体の構成図 今回の出展では、複数の四足歩行ロボットを動かして点検をデモしたり、同時にドローンの映像をintdashへ転送したりといった実演を通じて、メーカーも種類も異なる機体・センサーを、intdashという1つのデータ基盤の上で運用する様子を、実機と画面でそのままご覧いただきました。 会場の印象 会場を歩いていて印象的だったのは、点検ロボットやドローンを展示しているだけでなく、実際に動かしているブースが非常に多かったことです。人手不足を背景に、インフラ・プラントの点検をいかに自動化・省人化するかというテーマが、実証段階から運用段階へ移りつつあることを感じました。 アプトポッドブースの展示 アプトポッドブースの様子 点検・警備ソリューション 点検や警備の分野では、人手不足が課題になっているというお話をうかがうことが特に多くなっています。よくうかがう課題は、人が現場に行かないと状況が分からないこと、計器の値を人が目視で読む必要があること、定置センサーがない箇所は人が足を運ぶしかないことです。 ブースの前面では、「カメラやセンサーを搭載したロボットが自律的に現場を歩いて移動する」「ロボットが撮影した画像をAIが解析して数値にする」「ロボットからのデータとAIの解析結果を、すべて1つのintdashの画面でリアルタイムに見る」という組み合わせで実演しました。 ブース内には昇降ステップやダミーの計器を配置して簡易的なプラントを模擬し、そのなかを Unitree Go2 や Unitree A2 が走行しました。 デモエリアを歩き回るロボットたち Unitree Go2 では、 パナソニック アドバンストテクノロジー株式会社 様の自律移動ソフトウェア「@mobi」を使い、事前に作成した地図とウェイポイントに沿ってブース内を巡回します。頭部カメラに加えて、背中に3D LiDAR（Livox Mid-360）と360度カメラ（Insta360 X5）、そしてCO2センサーを搭載しました。 adtsd.jpn.panasonic.com Go2の背中。3Dプリンタ製のケースに360度カメラとアンテナ、CO2センサーを載せています Unitree A2 は最近発売された新機種で、防塵防水に対応しており、重いペイロードも搭載できます。今回は自律走行は行わず、intdashを経由した遠隔操縦のデモを行いました。遠隔操縦だけでなく、 株式会社ザクティ 様のPTZカメラの向きを遠隔から操作できるようにし、さらに 理研計器株式会社 様のマルチガスセンサー GX-3R Pro を搭載して、ガスのセンサー値をリアルタイムにintdashへ送りました。PTZカメラを遠隔からパン・チルト・ズームさせて、離れた場所の計器を読みに行く、という使い方ができます。 A2の背中。PTZカメラとマルチガスセンサーを搭載しています product.rikenkeiki.co.jp xacti-co.com ブースの入り口で展示していた Unitree Go2-W は、脚の先が車輪になっているモデルで、こちらには TechShare 社株式会社 様の自律移動パッケージ「Patrobot」を載せています。搭載しているのはCO・アルコールガスセンサーと放射温度計。ガス漏れと発熱という、プラント点検で真っ先に見たい2つを歩きながら測るイメージです。 展示では昇降ステップを並べて段差を作り、ロボットが階段状の障害物を昇り降りする様子もご覧いただきました。 ブース内を自律走行して、メーターの自動読み取りを行うUnitree Go2 techshare.co.jp メーター読み取り アナログ計器は、人が値を目視で読み取って記録する作業が必要です。それを自動化する例として、ロボットのカメラ映像からメーター領域を切り出し、「hakaru.ai」 の認識APIに問い合わせて数値に変換するデモを行いました。 読み取った値は、そのまま intdash の時系列データとして扱えます。intdashへ送ることで、カメラの映像などと並べてメーターの読み取り値を確認できます。また、リアルタイムに見るだけでなく、あとからAPIを利用して回収することもできます。 切り出されたメーター画像と読み取り値。CO2濃度や人物検出数と同じ画面に並びます www.hakaru.ai 四足歩行ロボット以外の連携：ドローン・ウェアラブルカメラ・サーマルカメラ 四足歩行ロボット以外にも、ドローン、ウェアラブルカメラ、サーマルカメラとの連携を展示しました。 ドローンのデモでは、ドローン搭載カメラのライブ映像をintdashへ送り、高所や空中からの確認が可能なことを紹介しました。俯瞰位置に設置したサーマル監視カメラ（EDGEPLANT T1 経由）では、RGB映像とサーマル映像を同時に配信し、温度異常を色で確認できることを紹介しました。 株式会社ザクティ 様のウェアラブルカメラは Raspberry Pi 経由で接続し、ブレ補正された作業者目線の映像を送れることを実演しました。 これらの映像については、サーバー側でYOLOによる人物・物体検出を行い、映像を後処理して検知することも可能であることをデモしました。 ロボット・固定カメラ・人・ドローンという性格の違うデータソースを、intdashで統合して確認できることが、このソリューションの大きな特長の一つです。 ドローンの映像も、ロボットやカメラと同じ画面で確認できます xacti-live.com 通信 各ロボットには回線ボンディングに対応した Peplink MAX BR2 Micro を利用し、混雑した会場内でも2回線を束ねることで安定したモバイル通信を実現しました。 www.caso.co.jp リアルタイムデジタルツインソリューション このエリアでは、施工現場の状況を仮想空間に再現するリアルタイムデジタルツイン基盤をご覧いただきました。画面には現場の3D点群が広がり、その上に車両の走行軌跡が重なります。同じ画面の中に掘削量・盛土量といった土量の数値、地表の断面形状のグラフ、そして車載カメラの映像が並び、すべてが同じ時間軸で再生されます。「現場のいつ・どこで・何が起きていたか」を、後から3D空間ごと巻き戻して確認できる、というイメージです。 3D点群の上に車両の走行軌跡、土量、断面形状、車載カメラ映像が同じ時間軸で並びます 実際に動いている様子は、こちらの動画でご覧いただけます。 www.youtube.com 映像3Dモデル化デモ ブースを iPhoneアプリ intdash Motionで撮影した映像データを、 株式会社Liberaware 様が提供する「 LAPIS 」に連携して点群化し、3Dモデルとして表示しました。 専用の3Dスキャナーだけでなく映像を起点として空間を3D化できるため、設備や現場の状況把握、遠隔からの確認など、さまざまな活用が期待できます。映像を見るだけの監視から、空間として記録・参照する活用へ広がる点が興味深い展示でした。 www.youtube.com フィジカルAI フィジカルAIのエリアでは、これから応用が進んでいくであろうこの分野でも、intdashを活用できそうな事例をご紹介しました。 ロボットやAIを現場で賢く動かすには、大量の現実世界のデータが必要です。一方で、危険な状況やめったに起きない事象は、実環境ではなかなか集められません。そこで、実環境から集めたデータと、シミュレーション環境（Gazeboなど）で生成したデータを、intdash で同じように収集・蓄積する構成をご紹介しました。 あわせて、学習データの収集からアノテーション、モデル開発、実機へのOTAによるモデルデプロイ、そして運用時の遠隔監視・遠隔診断・遠隔制御介入までを一連のパイプラインとして構成する取り組みも、 FastLabel 株式会社様との連携例としてご紹介しました。動画像と関節角度・圧力といったマルチモーダルなデータを、時刻を揃えたまま時系列データベースに蓄積できることが、この構成の前提になっています。 収集したデータを使える形に整えるデータ加工レイヤも重要です。データ収集レイヤであるintdashから必要な時系列データを取得し、解析処理を行ったうえで、運用に必要な形に出力する仕組みが求められます。その一例として、Power BIとintdashを連携させるデモを展示しました。 データ収集レイヤ・加工レイヤ・活用レイヤの3層構成 来場者の反応 ブースでは、プラントや工場の設備保全、倉庫や施設の点検業務のDX推進など、さまざまな立場の方にお立ち寄りいただきました。 四足歩行ロボットによる巡回点検の展示について、反応を多く頂きました。ロボットの導入を考えてはいるものの、まず何から始めればよいのか悩んでいる、という声も多くうかがいました。 「カメラやセンサーはすでに導入しているが、形式も周期もばらばらで突き合わせられない」といった、データのサイロ化に関する課題を挙げられる方もいらっしゃいました。マルチモーダルな時系列データを時刻を揃えて収集するという intdash のアプローチについて、その必要性を実感を持って受け止めていただけたケースも多かったように思います。 まとめ メンテナンス・レジリエンス 2026 にご来場いただき、アプトポッドブースにお立ち寄りいただいた皆さま、誠にありがとうございました。 アプトポッドは、intdash を通じて、現場点検のロボット化・遠隔化、複数のカメラやセンサーを統合したリアルタイム可視化、現場のデジタルツイン化、ロボット・AI開発のためのデータ基盤といった、さまざまな領域で現場のデータ活用を支援してまいります。お困りごとがありましたら、ぜひ お問い合わせフォーム からご連絡ください。