Access学習メモ 0-13. AIビジネスへの防波堤作り

Access学習メモ 0-13. AIビジネスへの防波堤作り

記事
学び
勤務先で作成したAccessの「Job管理簿」に
顧客データ「申請事業所」フィルタリング用のコンボボックスを
配備したいと考えた。
コンボボックスの名称.png

事業所名を(テーブル引用ではなく)レコードに直接入力する仕様であるため
事業所に関する情報がそれ専用のマスタテーブルにまとめられた状態の
通常フォームにおけるコンボボックス設計手順をとった場合
通常のコンボ設定.png

同一事業所名がレコード(記入済みデータ)の数だけ全登場する仕様となる。
通常の設定だと重複データが表示される.png

同じ事業所名が数百行あったとしても
フィルター上の選択肢としては、1事業所につき1行表示されれば足りる。

今回は準備にかける時間の確保がむずかしく
背に腹は代えられず、人工知能AIから情報の提供を受けてみた。
①Microsoftが提供するCopilot(有償)にてドラフトを作り
②Googleが提供するGemini Noteboook(無償)にて検証。
問題なければ、Accessにて実装/動作確認をおこなう。

今回の「重複データ問題」については
「DISTINCT」句を使えばいいとCopilotから提案あり。
SELECT DISTINCT フィールド名
FROM テーブル名

なるほど、値集合ソース内で重複データ抽出にブロックをかけたあと、
値集合にセット.png
通常のコンボボックス更新後処理イベントモジュールへ情報を渡す。
イベントモジュール設定.png

GoogleAIにて手順を審査したところ、手ごたえあり
(無料版Gemini Noteboookによる最終コメント)
Geminiの返答.png
プロパティシート「データ」→「値集合ソース」から
SQLビューを開いて、
SQL記入場所.png

下記コードを搭載してみる。
SELECT DISTINCT 事業所名
FROM T_Job管理簿
ORDER BY 事業所名;
値集合クエリSQL.png

これで「値集合ソース」のクエリビルダー設計が完了した。
デザインビューだとこんな感じ。
値集合のデザインビューはこんな感じ.png

更新後処理(コンボボックスのフィルタリング後の行動指示)イベントとして
下記コードを記入する。
ユーザーがコンボボックスで選択中の事業所名を消去し空欄に戻したとき
フィルタを解除して全件表示に戻す(Me.FilterOn = False)If句を追加。

Private Sub Cmb事業所_AfterUpdate()
If IsNull(Me.Cmb事業所) Or Me.Cmb事業所 = "" Then
        Me.FilterOn = False
    Else
    Me.Filter = "申請事業所='" & Me.Cmb事業所 & "'"
        Me.FilterOn = True
    End If
End Sub

※事業所名が「B'z」など、名称に "'(シングルクォーテーション)"が含まれる場合、データ読み込みが正常におこなえない可能性があるため、
 保険として "'"を "''(シングルクォーテーション×2)"に置き換えるReplace関数を加えることで、よりビジネス向きの設計に近づくとも。
Me.Filter = "申請事業所='" & Replace(Me.Cmb事業所, "'", "''") & "'"

本来なら必要ないはずの作業工程を、そうとは応えず
懇切丁寧に掘り下げるAI
AIの説明は、まるでこちらの知識量を試すかのように
ごく基本的な情報開示を端折ることが多い。
今回は、とりわけ重要な下記ポイントがスルーされていたと判明。

ポイント1:
分割フォームには、あらかじめ設計されたデータシートビューにおいて
全フィールドにデータ絞り込みのためのフィルタリング機能を搭載済み。
分割フォームにおいては、検索用コンボボックスはそもそも必要ない。

ポイント2:
検索用コンボボックスは、他の入力用テキストボックスと違い、表示専用。
テキストボックスと同じ感覚で詳細セクションに置くと
詳細セクションに置いた時の例.png

Accessはそれを、レコードの一部として認識してしまい
データシート上に、必要のないコンボボックスフィールドが追加される。
詳細セクションに置くと勝手にフィールドが作られた.png

コンボボックスは詳細セクション以外のセクションに設計する。
(フォームヘッダに配備するのが一般的。)
検索窓の配置場所.png

無事に作られたようです。
正常にコンボボックスが表示.png

ポイント3:
動作確認の前に、プロパティシートで各項目の最終確認を行う。
値集合ソース(クエリ)や動的処理(VBA)の設計を丁寧におこなっていても
コード上の各コントロールの名称が1文字でも違っていたり
クエリビルダーやイベントプロシージャ紐づけが各コントロールから外れると
(修正を繰り返す過程でリンクが解消されることが多い)
設計者の意図がフォームに伝達されず、エラーの要因となる。

反省点
ポイント1にあるとおり、やらなくていいことで長時間、悩んでしまったことが悔やまれる(´σ_σ`)
本来はAIに相談することなく秒で解決、この記事も生まれなかっただろう。
今回使用したAI製品は、いずれも投稿を二次利用しないことを各企業が明言しているものの、それを確かめる術を持ち合わせない以上、注意が必要だ。
「AIに相談したが問題は解決せず、ただ情報を明け渡すだけに終わった」
では、目も当てられない。

情報の取捨選択タスクは、AI導入以前も現代も変わらない!
今回、何故かAIが指摘してこなかった上記のポイントについては、
AIが言及した「社名のシングルクォーテーション(')エラー回避策」よりも
遥かに重要度も優先順位も汎用性も高いように思う。

今回、意図的にAIへ試し行為を仕掛けたわけではない。
Accessで分割フォームを使うのは自分にとって初めてのケースであり
リサーチ不足ではあった。
頭のネジが抜けているのもいつものことだ。

当然のことだが、AI自身がAccess操作経験を持つわけではない。
基礎学習や実践の積み重ねによる経験則を味方につけなければ
ムダな掘り下げに時間や感情を食い尽くされてしまうことを
今回あらためて痛感した。
職場では有料版(業務用+Access学習用)
自宅では無料版(Access学習用)を使っているが
有料版だから形成される回答の精度が格別高いというわけではない。
(有料版Copilotによる最終コメント)
Copilot.png

「AIを使いこなせるよう、人間はもっと学習すべき」なのか?
AccessもAIも、民間企業の提供サービスに過ぎない。
それらに関する「学習」の正体もまた、単なる操作マニュアルの習得。
便利な道具を快適に使いこなせたらと願うユーザーの自由意思に委ねられ
学校教育における「学習」のように義務化されたわけでも第三者から強要されるものでもない。

ただ...「部下が作った原稿を上司が審査する」従来の会社組織の仕組みが
徐々に「AIが原稿を出力し、人間がそれを審査する」仕組みへとシフトチェンジしつつあるのは事実で
部下の業務を理解・把握していなければ、上司として真っ当な内容審査を行えないのと同様に
「面倒な作業はAIに任せて、人間はその傍らで仕事をした気になっていればいい」なんてことはなく
「AIによる成果物が妥当か否か、ニーズに合った適材適所な情報か否か」
正確に判定する目利きは今後、より欠かせない領域になる。

一般人が無免許無資格で市場に参入できる上に
ユーザーの数だけ多種多様な需要が見込まれるため
AIビジネスは、今後も拡充し続けるだろう。
相談、描画、翻訳、添削、吹替・・・

ステレオタイプの成功例ばかり目を引く一方で、今回経験した情報の脆弱性、
役目を終えたAIサーバーやGPU、冷却設備、配電インフラ等の不適切処理、
1会話のパラメータ稼働に大量の電力や冷却水が消費される現実に言及する情報は目立ちにくい。
AIは電気や水なしでは動けない。成果物は必ずしも完璧ではない。
そして...責任は一切負わない。

AI同士の食物連鎖で成り立つ空虚なビジネスに、息を吹き込むのは人間
人間なりの五感を駆使した業務チェックのルーティン化は切実な課題だろう。
こつこつと知識や経験を積み、マネーゲームに流されないための防波堤を自分なりに築くしかない。
分割フォーム全容.png

サービス数40万件のスキルマーケット、あなたにぴったりのサービスを探す