生成AIでIPAシステムアーキテクト試験問題に取り組む
はじめに
生成AIと教育や学習はとても相性が良いのではないかと考えているので、その実用的な方法を検証してみたいと思います。また実業務においても要件定義書の作成やその内容の解釈および内容の図式化、モデル化にも活用できるのではないかと思われるため、それらについて少しでも具体的なユースケースを考えながら検証していきたいと思います。
今回は、題材としてIPA主催のシステムアーキテクト試験の2024年春の過去問題を使って、試験内容の学習をしてみます。
当記事の要約
*Gemini1.5 Proで要約
生成AIでシステムアーキテクト試験の過去問学習: 可能性と課題
著者は、生成AI(Gemini 1.5 flash)を用いてシステムアーキテクト試験の過去問学習を試行し、その可能性と課題を検証した。
可能性:
自然文の説明からシステム構成図、ER図、テーブル定義などを自動生成できるため、問題理解の効率化が図れる。
問題の趣旨や重要ポイントを質問することで、より深い理解を得られる。
新しい問題と解答例を自動生成することで、応用力の強化に繋がる可能性がある。
課題:
適切なアウトプットを得るためには、プロンプトの工夫や試行錯誤が必要となる。
生成された結果の正誤判定には、依然として専門知識が不可欠である。
長文のインプットや複雑な処理は、性能や課金面で課題が残る。
結論:
生成AIは試験学習を効率化する可能性を秘めているが、現状では人間の知識や判断力と組み合わせる必要があり、更なる技術の進化と活用方法の探求が求められる。
環境
- 今回はGoogle CloudのVertex AIのマルチモーダルGUIを使って操作を行います。
- 途中に出力されるMermaid形式のテキストを図で表示する際には、Mermaid Live Editorや、ローカルPCのIDE（ちなみに僕はCursorを使用）のプラグイン等を使います。
- モデルはGemini 1.5 flashを使って検証します。これにした理由は特にはありません。もちろんモデルが変わると以降の結果が変わる可能性はおおいにあります。特にGemini系ではなく例えばClaude系などを使うとまた違った答えが返ってくることも期待できます。
準備
インプットデータの準備
IPAの情報処理技術者試験のサイトより、以下の過去問題をダウンロードします。
こちらは一応PDF形式なのですが、紙の原稿をスキャンした画像をそのままPDFとして保存した形式でした。
PDFファイルのテキスト化
このままだとテキスト化できないので、一旦Gemini 1.5（今回はFlash）を使ってPDFファイルをアップロードし、その際に「このファイルに書かれている問1を一語一句漏らさずに文字起こしをしてください。」などといった指示（プロント）を与えて処理を実行します。
なお、Gemini1.5系はマルチモーダル対応なので、わざわざ一度テキスト化しなくても良さそうではありますが、今回の検証では元々PDFの内容をベクトルデータ化したいという要求もあったのでテキスト化しています。ともかく、後からプロンプトを使って微修正や再質問することを考えると一度テキスト化しておいたほうが効率的ではあります。
テキスト化した結果はこちら
問1 システムの統合に関する次の記述を読んで、設問に答えよ。
A 社は、加工食品の製造・販売を行うメーカーである。 このたび、乳飲料の製造・販売を行う B 社を吸収合併することになった。 合併後も両社はそれぞれの工場で従来ど���り製造を継続するが、業務効率化のため、システムは一つに統合することにした。
〔A 社と B 社の品目と工程の概要〕
両社は、仕入先から調達を行う原材料、中間工程で製造される仕掛品、最終工程で製造されて得意先へ販売する製品の三つを取り扱っている。 原材料、仕掛品、製品のそれぞれに属する品物を品目と呼ぶ。 両社の製造工程は、仕込、調合、殺菌、充填の四つの工程から成り立ち、各工程では一つ以上の原材料又は仕掛品を投入し加工して、一つの仕掛品又は製品を製造する。 一つの仕掛品又は製品は、一つの工程で製造される。 製造の流れを図 1 に示す。
原材料 A (仕込) 原材料 C 原材料 B 工程 101 原材料 D 原材料 E 工程 102 仕掛品 a 仕掛品 m 仕掛品 (調合) 工程 201 仕掛品 b (殺菌) 工程 301 仕掛品 (充填) 工程 401 製品 1 仕掛品 工程 202 仕掛品 工程 302 仕掛品 工程 402 製品 2
図 1 製造の流れ
A 社は、製品を見込生産しており、製品の製造に数日を要する。 製品は数か月間保管が可能であることから、在庫管理を行っ��いる。 原材料も在庫管理を行うが、仕掛品は品目によって在庫管理を行うものと行わないものがある。
B 社は、製品を受注生産しており、前日に受注した製品を全て当日に製造する。 製品は製造後、直ちに出荷されるので在庫管理を行わない。 また、仕掛品も製造後、直ちに次の工程に投入されるので在庫管理を行わない。 原材料は表計算ソフトを用いて在庫管理を行っている。
[A 社の業務の概要]
販売戦略部が策定した製品の販売計画を基に、数か月先までの製品の生産計画を、日別品目単位に立案する。 その後、販売実績を加味して、製造日の 2 週間前に、生産計画を確定する。
A 社では、販売戦略上、製品を生産計画で定めた期日までに効率的に製造することが求められている。 翌々週の生産計画に基づいて、充填、殺菌、調合、仕込の順番で各工程の所要時間を計算し、製品及び仕掛品の製造指示、並びに仕掛品及び原材料の投入指示を、工程単位に作成する。 各工程の製造指示は、期日に合わせて製造するためには遅くともいつから当該工程の製造を開始しなければいけないかを考えて、開始予定日時を決定した上で作成する。 各工程の投入指示は、製造指示数を基に、必要となる原材料や仕掛品の数を計算して作成する。
各工程の想定所要時間は、製造する数に比例する場合と、数によらないで一定の時間 を要する場合がある。 数に比例する工程は単位当たり所要時間、一定の時間を要する工程は固定の所要時間が、製造される品目ごとに決まっている。
また、原材料について、投入指示数と現在の在庫数に基づいて仕入先から調達する数を決定し、納品日別品目単位の発注数を仕入先に送信する。
製造指示と投入指示に基づいて製造設備に原材料や仕掛品の投入を行い、仕掛品又は 製品を製造する。 一つの品目は、1 日に 1 回まとめて製造する。
各工程の終了後すぐに、製造担当者が製造実績及び投入実績を登録する。
得意先からの受注に基づき製品を出荷する。 製品の製造実績、出荷実績を基に製品の在庫管理を行う。
[A 社のシステムの概要]
A 社のシステムは、計画システム、生産管理システム、販売管理システム、及びマスター管理システムで構成されている。
(1) 計画システムでは生産計画を管理する。 販売戦略部が策定した製品の販売計画を取り込む。 販売管理システムから販売実績データ及び製品の在庫数を取得し、製品の生産数を決定して生産計画データを作成する。
(2) 生産管理システムでは、計画システムから翌々週の製品の生産計画データを取得する。 製品の生産数を基に、各工程の所要時間を計算して、製品及び仕掛品の工程単位の製造データを作成し、その製造データを基に、所要量マスターを使って投入品目ごとに投入指示数を決定し、投入データを作成する。 全てのデータが出そろったら、製造日時などの重なりを調整して製造データ及び投入データの修正を行う。 全ての投入データ作成後に、集計した投入指示数を原材料の在庫数から減算した結果が、別途定められた最低在庫数を下回る場合は、仕入先から調達する。 仕入先へは、1 日に 1 回、A 社で定めた様式の発注書を添付して、電子メールで送信する。 各工程の製造が終了した時点で、製造担当者がタブレット端末を用いて、製造データ、投入データの実績を登録する。 これらの実績を用いて、原材料及び在庫管理が必要な仕掛品について、在庫データを更新する。 製品の製造工程に関する製造データを、販売管理システムに送信する。 また、夜間に工場の稼働率などの管理指標値を集計し、翌日に本社から参照可能にする。
(3) 販売管理システムでは、製品の受注、出荷、在庫管理を行う。 出荷データ、生産管理システムから受信した製品の製造工程に関する製造データで製品の在庫データを更新する。 また、販売実績データ及び製品の在庫数を計画システムに送信する。
(4) マスター管理システムでは、品目マスターや工程マスターなどに設定が必要な データを入力し、各システムに送信する。
A 社の生産管理システムの主要なファイルと主な属性を表 1 に示す。
表 1 A 社の生産管理システムの主要なファイルと主な属性
主な属性 (下線は主キーを示す)
ファイル名
生産計画
製造
投入
在庫
品目マスター
工程マスター
工場コード、製造終了年月日、製造品目コード、生産数
工場コード、製造開始予定年月日、工程コード、製造指示数、想定所要時間、開始予定日時、終了予定日時、製造実績数、開始実績日時、終了実績日時
開始予定日時、投入指示数、投入実績数
工場コード、品目コード、在庫数、在庫更新日時
品目コード、品目分類 (“原材料”, “仕掛品”, “製品”), 品目名称、単位、保管可能日数、在庫管理有無フラグ (“有”, “無”)
工場コード、工程コード、製造品目コード、工程名称、時間計算区分 (“比例”, “一定”), 所要時間
品目マスターでは、原材料、仕掛品、製品を区分するために、品目分類を設定して管理している。 各品目は、その特性に応じてキログラム、リットル、個といった単位で管理されており、生産数、製造指示数などはその単位で数えた数である。 また、品目によっては在庫管理を行わないものがあるので、在庫管理有無フラグを設定して管理している。 工程マスターでは、各工場で、全ての工程に、製造品目コード及び工程が一意に決まる工程コードを付与して管理している。
[B 社の業務の概要]
得意先からの受注に基づき、翌日の製品の生産予定数と翌日の製造の開始予定時刻及び終了予定時刻を、品目単位に立案する。 一つの製品を、1 日に複数回製造する場合がある。
翌日の生産予定に基づいた各工程の製造指示を作成する。 また各工程で必要となる原材料や仕掛品の数を計算し、投入指示を作成する。
作成した投入指示を基に、必要な原材料と数を、表計算ソフトを用いて集計する。 集計した投入指示数を原材料の在庫数から減算した結果が、別途定められた最低在庫数を下回る場合は、仕入先から調達を行うことにし、発注書を添付して電子メールで送信する。 発注書の様式は、各仕入先の要望に応じて表計算ソフトを用いて作成しており、複数の様式が存在する。
製造指示に基づき仕掛品又は製品を製造し、製品は、製造後に得意先に出荷される。 製造担当者が、製造現場で製造実績と投入実績を手書きで記録表に記入する。 月次処理で、製造実績と投入実績の集計表を出力するために、月末に記録表を参照し、まとめて生産管理システムに入力しているが、転記ミスの発生が問題視されている。 また、製造担当者の月末の入力作業の負荷が高いこと、及び本社管理部門で管理指標値が翌月にならないと確認できないことが問題視されている。
〔B 社のシステムの概要〕
B 社のシステムは、受注出荷システムと生産管理システムで構成されている。
(1) 受注出荷システムでは、得意先から EDI を用いて受注データを受信し、得意先ごとの受注データの仕様に合わせたデータ交換プログラムが稼働している。 受注データは、受注出荷システムに蓄積されるとともに、生産管理システムに送信される。 受注出荷システムでは受注修正、出荷実績登録、及びマスターデータの入力を行っている。
(2) 生産管理システムでは、製造指示・投入指示作成、原材料調達及び製造実績・投入実績入力並びにマスターデータの入力を行っている。 また、製造実績や投入実績を製造の翌月に集計し��本社管理部門に帳票として提供している。
〔システム統合の方針〕
・B 社のシステムは廃止し、A 社のシステムに一本化する。
・B 社はできるだけ、A 社のシステムをそのまま用いる。 製品の製造については現行どおりとするが、業務の運用もできるだけ A 社の運用に合わせる。 どうしても対応できない部分に対してだけ、改修や追加を行う。
・B 社のマスターは全て A 社のマスターに移行する。 B 社のコードを A 社のコードに読み替えるが、A 社で使われていないコードは、新たにコードの割当てを行う。 品目マスターの移行では、①B 社になかった在庫管理有無フラグには、ある規則に従って値を設定する。
・B 社の製品を現行どおりに製造できるよう、②ある属性を表 1 中の二つのファイルの主キーに追加する。
・A 社の販売管理システムには EDI の機能がないので、得意先ごとの受注データの仕様に合わせたデータ交換については、B 社の EDI の機能に必要な修正を加えた上で、統合後の販売管理システムに取り込む。
・統合後の生産管理システムに、B 社の得意先からの受注データを基に、翌日の製造データ及び投入データを作成する機能を追加する。
・B 社の原材料調達業務を実施するに当たり、仕入先に変更点を説明して、仕入先に業務手続を変更してもらうよう依頼する。
〔システム稼働後の評価〕
統合したシステムの稼働後、合併前に B 社で行っていた業務がどのように変わったかを評価し、効果を次のようにまとめた。
・記録表からの転記ミスがなくなり、正確な数字が把握できるようになった。
・③ある作業が削減されたことで、製造担当者の作業の負荷が平準化された。
・本社管理部門における業務の改善が実現できた。
設問 1 A 社の製造データの作成について答えよ。
(1) 製造指示及び投入指示を作成する際、充填、殺菌、調合、仕込の順番に作成している理由は二つある。 その一つは、後工程で算出された仕掛品の投入指示数に基づいてその仕掛品の製造指示数を決めるからである。 もう一つの理由を 40 字以内で答えよ。
(2) 製造データを作成する際、各工程の想定所要時間はどのように求めるか。 時間計算区分が “比例” 又は “一定” のそれぞれについて、表 1 中の属性と、必要に応じて四則演算子を用いて答えよ。
設問 2 〔システム統合の方針〕について答えよ。
(1) 本文中の下線①で在庫管理有無フラグの値を設定する規則を、30 字以内で答えよ。
(2) 本文中の下線②で主キーを追加するファイルを二つ答えよ。 また、追加が必要になった B 社の要件を、30 字以内で答えよ。
(3) B 社が、合併後に統合後のシステムを利用して原材料調達業務を実施するに当たり、仕入先に依頼する業務手続上の変更点は何か。 25 字以内で答えよ。
設問 3 〔システム稼働後の評価〕について答えよ。
(1) 本文中の下線③のある作業とは何か。 40 字以内で答えよ。
(2) 本社管理部門の業務はどのように改善されたか。 その内容を 30 字以内で答えよ。
文字起こしした内容のチェック
文字起こしした結果が元の文書と違っていたら元も子もありませんので、内容が正しいかをチェックします。今回は元の文書が画像形式なのでもはや目視確認する他ありません。頑張ってチェックした結果、確かに一語一句間違いなく文字起こしされていました。
1年前では考えられませんが、現在の生成AIモデルの画像の読み取り精度は劇的に向上しています。
この結果からすると、精密に内容のチェックをせずとも信頼してもよいのではないかと思われます。（がそれで良いか否かの判断は結局はユースケース次第かと思われます）
ちなみに、文字起こし結果は利用モデル次第、または同じ利用モデルでも時には、例えば改行や段落区切りがされずに人間には読みづらい出力結果になったりすることがありました。その場合には、再度処理を実行する、そしてその際には今度は「改行や段落区切りも正確に記述してください」などとより具体的に要望を伝え指示することにより、この問題は解消します。
検証したユースケース
では準備ができたところで、早速以下のユースケースを設定して実際に指示をしていきたいと思います。
システム構成図を作成するように指示する
システムアーキテクト試験の午後1問題の、問1には、ある会社（A社）のシステム構成に関する説明が自然文で書かれています。これをシステム構成図として表現するように指示してみます。
問１で説明されている [A社のシステムの概要〕 を解釈して、Mermaid記法を使ってシステム構成図を作成してください。
すると、結果はMermaid形式のテキストで出力されます。
graph LR
A[A社システム] --> 計画システム[計画システム]
A --> 生産管理システム[生産管理システム]
A --> 販売管理システム[販売管理システム]
A --> マスター管理システム[マスター管理システム]
計画システム --> 販売戦略部[販売戦略部]
計画システム --> 販売管理システム
販売管理システム --> 販売実績データ[販売実績データ]
販売管理システム --> 製品在庫数[製品在庫数]
販売管理システム --> 計画システム
生産管理システム --> 計画システム
生産管理システム --> 所要量マスター[所要量マスター]
生産管理システム --> 投入データ[投入データ]
生産管理システム --> 製造データ[製造データ]
生産管理システム --> 原材料在庫数[原材料在庫数]
生産管理システム --> 製造設備[製造設備]
生産管理システム --> 販売管理システム
マスター管理システム --> 各システム[各システム]
特にこの形式で出力するように指示はしていませんが、最初から明示的に指示し、かつもっと具体的な内容の指示をするとより自分が望む結果となると思われます。
このMermaid形式の結果は、Mermaid Live Editor等で確認してみます。
説明文と比較してみると概ね合っていそうではありますが、何度か質問するとその度に少しずつ図が変わることがあるため、あくまで内容を理解するためのベース程度で捉えつつ、自分で内容を理解しながら修正をしたほうがよいかもしれません。
DBのテーブル定義を表形式で作成するように指示する
次に、ER図を作成してみます。問1には、以下のようなテーブルが表形式で説明、提示されています。
生成AIによる文字起こしの際には、以下のとおりに出力されたのでこれをインプットにして、再度テーブル形式として表示するように指示します。
表1 A社の生産管理システムの主要なファイルと主な属性をmermaid形式で表にしてください。
結果は以下のとおり。
table
| ファイル名 | 主な属性 |
|---|---|
| 生産計画 | 工場コード, 製造終了年月日, 製造品目コード, 生産数 |
| 製造 | 工場コード, 製造開始予定年月日, 工程コード, 製造指示数, 想定所要時間, 開始予定日時, 終了予定日時, 製造実績数, 開始実績日時, 終了実績日時 |
| 投入 | 工場コード, 製造開始予定年月日, 工程コード, 投入品目コード, 開始予定日時, 投入指示数, 投入実績数 |
| 在庫 | 工場コード, 品目コード, 在庫数, 在庫更新日時 |
| 品目マスター | 品目コード, 品目分類( "原材料", "仕掛品", "製品" ), 品目名称, 单位, 保管可能日数, 在庫管理有無フラグ( "有", "無" ) |
| 所要量マスター | 製造品目コード, 投入品目コード, 投入数 |
| 工程マスター | 工場コード, 工程コード, 製造品目コード, 工程名称, 時間計算区分( "比例", "一定" ), 所要時間 |
元画像の内容と遜色ない結果ですが、下線による主キーだけは再現できていませんでした。
ER図を作成するように指示する
次に、ER図を作成してみます。前述のテーブル定義を元にER図を作成するように指示します。
表1 A社の生産管理システムの主要なファイルと主な属性を、Mermaid記法を使ってER図にしてください。
結果はこちら
erDiagram
生産計画 ||--|{ 製造品目: 製造品目コード
生産計画 ||--|{ 工場: 工場コード
製造 ||--|{ 製造品目: 製造品目コード
製造 ||--|{ 工場: 工場コード
製造 ||--|{ 工程: 工程コード
投入 ||--|{ 工程: 工程コード
在庫 ||--|{ 品目: 品目コード
在庫 ||--|{ 工場: 工場コード
品目マスター ||--|{ 品目: 品目コード
所要量マスター ||--|{ 工程: 工程コード
所要量マスター ||--|{ 品目: 品目コード
工程マスター ||--|{ 工程: 工程コード
生産計画 {
工場コード VARCHAR(10)
製造終了年月日 DATE
製造品目コード VARCHAR(10)
生産数 INT
}
製造 {
工場コード VARCHAR(10)
製造開始予定年月日 DATE
工程コード VARCHAR(10)
製造指示数 INT
想定所要時間 INT
開始予定日時 DATETIME
終了予定日時 DATETIME
製造実績数 INT
開始実績日時 DATETIME
終了実績日時 DATETIME
}
投入 {
開始予定日時 DATETIME
投入指示数 INT
投入実績数 INT
}
在庫 {
工場コード VARCHAR(10)
品目コード VARCHAR(10)
在庫数 INT
在庫更新日時 DATETIME
}
品目マスター {
品目コード VARCHAR(10)
品目分類 VARCHAR(10)
品目名称 VARCHAR(50)
单位 VARCHAR(10)
保管可能日数 INT
在庫管理有無フラグ VARCHAR(2)
}
所要量マスター {
工場コード VARCHAR(10)
投入予定年月日 DATE
工程コード VARCHAR(10)
投入品目コード VARCHAR(10)
製造品目コード VARCHAR(10)
投入数 INT
}
工程マスター {
工場コード VARCHAR(10)
工程コード VARCHAR(10)
製造品目コード VARCHAR(10)
工程名称 VARCHAR(50)
時間計算区分 VARCHAR(2)
所要時間 INT
}
工場 {
工場コード VARCHAR(10) PRIMARY KEY
工場名 VARCHAR(50)
}
工程 {
工程コード VARCHAR(10) PRIMARY KEY
工程名称 VARCHAR(50)
}
品目 {
品目コード VARCHAR(10) PRIMARY KEY
品目分類 VARCHAR(10)
}
製造品目 {
製造品目コード VARCHAR(10) PRIMARY KEY
製造品目名称 VARCHAR(50)
}
これをMermaid Live Editorで図として出力させようとすると、次のエラーとなります。
Error: Error: Parse error on line 2:
erDiagram 生産計画 ||--|{ 製造品目: 製造
-------------^
Expecting 'EOF', 'SPACE', 'NEWLINE', 'title', 'acc_title', 'acc_descr', 'acc_descr_multiline_value', 'ALPHANUM', 'ENTITY_NAME', got '生'
*なおこの出力結果は必ずしも一定ではない点には注意が必要です。
エラーメッセージを見たところ、日本語文字の扱い方の改善、Mermaid形式の構文エラーであることが推察されるので、以下のとおり指示をより具体的にします。
テーブル定義は、データ型、カラム名(英語),PK（もしある場合のみ）カラム名(日本語)の順番で書いてください。カラム名が日本語の場合はダブルクォーテーションでくくってください。 例えば、以下のように記述してください。
"生産計画" {
VARCHAR(255) factorycode PK "工場コード"
DATE production_end_date PK "製造終了年月日"
VARCHAR(255) product_code PK "製造品目コード"
INT production_quantity "生産数"
}
あわせて、以下の文章を上述のプロンプトに付け加えて実行します。（この場合、<u></u>は自分で加筆しました）
なお、以下のtableの属性のうち<u></u>で囲ったものは、そのファイルの主キーを意味します。
その結果はこちら
出力文字
erDiagram
"生産計画" {
VARCHAR(255) factorycode PK "工場コード"
DATE production_end_date PK "製造終了年月日"
VARCHAR(255) product_code PK "製造品目コード"
INT production_quantity "生産数"
}
"製造" {
VARCHAR(255) factorycode PK "工場コード"
DATE production_start_date PK "製造開始予定年月日"
VARCHAR(255) process_code PK "工程コード"
INT production_instruction_quantity "製造指示数"
INT estimated_required_time "想定所要時間"
DATETIME start_scheduled_time "開始予定日時"
DATETIME end_scheduled_time "終了予定日時"
INT production_achievement_quantity "製造実績数"
DATETIME start_achievement_time "開始実績日時"
DATETIME end_achievement_time "終了実績日時"
}
"投入" {
VARCHAR(255) factorycode PK "工場コード"
DATE production_start_date PK "製造開始予定年月日"
VARCHAR(255) process_code PK "工程コード"
VARCHAR(255) input_product_code PK "投入品目コード"
DATETIME start_scheduled_time "開始予定日時"
INT input_instruction_quantity "投入指示数"
INT input_achievement_quantity "投入実績数"
}
"在庫" {
VARCHAR(255) factorycode PK "工場コード"
VARCHAR(255) product_code PK "品目コード"
INT stock_quantity "在庫数"
DATETIME stock_update_time "在庫更新日時"
}
"品目マスター" {
VARCHAR(255) product_code PK "品目コード"
VARCHAR(255) product_classification "品目分類"
VARCHAR(255) product_name "品目名称"
VARCHAR(255) unit "単位"
INT storage_possible_days "保管可能日数"
VARCHAR(255) stock_management_flag "在庫管理有無フラグ"
}
"所要量マスター" {
VARCHAR(255) production_product_code PK "製造品目コード"
VARCHAR(255) input_product_code PK "投入品目コード"
INT input_quantity "投入数"
}
"工程マスター" {
VARCHAR(255) factorycode PK "工場コード"
VARCHAR(255) process_code PK "工程コード"
VARCHAR(255) production_product_code "製造品目コード"
VARCHAR(255) process_name "工程名称"
VARCHAR(255) time_calculation_classification "時間計算区分"
INT required_time "所要時間"
}
"生産計画" ||--|{ "製造" : "製造指示"
"生産計画" ||--|{ "在庫" : "在庫管理"
"製造" ||--|{ "投入" : "投入"
"製造" ||--|{ "工程マスター" : "工程"
"投入" ||--|{ "所要量マスター" : "所要量"
"品目マスター" ||--|{ "在庫" : "在庫管理"
"品目マスター" ||--|{ "所要量マスター" : "所要量"
"品目マスター" ||--|{ "生産計画" : "生産計画"
こちらを再びMermaid Live Editorで図として出力させると次は正常に図が表示されるようになりました。
問題に対する質問をする
＊この質問は、一度設問に対する回答の作成指示をした後にしています。そのため、質問の内容が設問の回答にやや引きづられたような印象があります。おそらく本来は問題の理解、設問の理解、設問の回答、と順にやりとりをしていったほうがより実のある学習が得られたのではないかと思われます。
問1の出題の趣旨はなんでしょうか？
問1の趣旨は、文章中に記述されているA社の業務内容とシステム概要、特に製造データの作成手順と算出方法、関連する属性の関係性を理解しているかを問うものです。
具体的には、
(1)は、製造指示と投入指示の作成順序が、後工程から逆算していく理由を理解しているか、工程間の依存関係を把握しているかを問う問題です。
(2)は、各工程の想定所要時間を算出する際に、時間計算区分によって異なる計算式と、必要な属性を正しく理解しているかを問う問題です。
つまり、問1は、文章からA社の生産管理における製造データ作成の流れと、それに必要な情報を読み取り、論理的に説明できる能力を測っていると言えるでしょう。
A社の業務とB社の業務の違いはなんでしょうか？違いを観点ごとに整理し、表形式で書いてください。なお表はmermaid形式のtable形式で書いてください。
| 観点 | A社 | B社 |
|---|---|---|
| 生産方式 | 見込生産 | 受注生産 |
| 生産計画 | 数ヶ月先までの生産計画を日別品目単位で立案 販売実績を加味し、製造2週間前に確定 |
翌日分の製品生産予定数と開始・終了予定時刻を品目単位で立案 1日に同一製品を複数回製造する場合あり |
| 在庫管理 | 製品、原材料、一部仕掛品を在庫管理 製品は数か月間保管可能 |
製品、仕掛品は在庫管理せず、製造後すぐに出荷・投入 原材料は表計算ソフトで管理 |
| 製造指示・投入指示作成 | 翌々週の生産計画に基づき、充填→殺菌→調合→仕込の順で作成 | 翌日の生産予定に基づき作成 |
| 原材料調達 | 投入指示数と在庫数に基づき、調達数を決定 納品日別品目単位の発注書を仕入先に送信 |
必要な原材料と数を表計算ソフトで集計 最低在庫数を下回る場合に調達 仕入先ごとに様式が異なる発注書を添付し、電子メールで送信 |
| 製造実績・投入実績記録 | 製造担当者が各工程終了後すぐにシステムに登録 | 製造担当者が製造現場で記録表に手書きで記入 |
| 管理指標値確認 | 翌日には確認可能 | 翌月にならないと確認できない |
問1の内容を正しく理解して解答する上で、特に把握しておくべき観点をあげてください。この際、このテストはシステムアーキテクトの能力を問うものである、という視点を盛り込んで考えてください。
問1の内容を正しく理解し、システムアーキテクトの視点で解答するためには、以下の観点を特に把握しておく必要があります。
1. 業務とシステムの関連性の理解
製造指示、投入指示の重要性: これらの指示はA社の生産計画に基づき、具体的な製造活動に落とし込まれたものであり、システムアーキテクトは、これらの指示がどのような流れで作成され、システムのどの機能と関連しているかを正確に把握する必要がある。
各システムの役割: 計画システム、生産管理システム、販売管理システム、マスター管理システムは、それぞれ異なる役割を担っており、互いに連携してA社の業務全体を支えている。システムアーキテクトは、各システムの機能と役割、そしてシステム間のデータの流れを理解する必要がある。
2. データ構造と属性の理解
各ファイルと属性の役割: 問1では、A社の生産管理システムの主要なファイルと属性が示されている。システムアーキテクトは、それぞれのファイルがどのようなデータを格納し、各属性が何を表しているかを理解する必要がある。特に、主キーと外部キーの関係を理解し、データの整合性がどのように保たれているかを把握することが重要。
時間計算区分の考慮: 想定所要時間の算出には、時間計算区分という概念が登場する。システムアーキテクトは、この区分が「比例」と「一定」のどちらであるかによって、計算式が異なることを理解し、適切な属性を用いて計算する必要がある。
3. システムアーキテクトとしての視点
効率性と正確性: A社のシステムは、「製品を生産計画で定めた期日までに効率的に製造すること」を目指している。システムアーキテクトは、この点を踏まえ、製造指示や投入指示の作成手順、想定所要時間の算出方法などが、効率的かつ正確な生産計画と実行にどのように貢献しているかを分析する必要がある。
保守性・拡張性: 問1は、既存システムに新機能を追加する状況を想定した問題も含まれている。システムアーキテクトは、既存システムの構造を理解した上で、新機能に必要なデータや処理を追加する際に、システム全体の整合性やパフォーマンスを損なわないよう、保守性・拡張性を考慮した設計をする必要がある。
これらの観点を踏まえて問1を分析することで、A社の生産管理システムに対する理解を深め、システムアーキテクトとして適切な解答を導き出すことができます。
設問に回答させる
ではいよいよ、設問について回答させてみましょう。
問1
プロンプト
問1の問題文を元に、設問 1の(1) (2) の回答を作成してください。
問題はこちら
設問 1 A 社の製造データの作成について答えよ。
(1) 製造指示及び投入指示を作成する際、充填、殺菌、調合、仕込の順番に作成している理由は二つある。 その一つは、後工程で算出された仕掛品の投入指示数に基づいてその仕掛品の製造指示数を決めるからである。 もう一つの理由を 40 字以内で答えよ。
(2) 製造データを作成する際、各工程の想定所要時間はどのように求めるか。 時間計算区分が “比例” 又は “一定” のそれぞれについて、表 1 中の属性と、必要に応じて四則演算子を用いて答えよ。
Gemini 1.5 flashの回答は以下のとおり
(1) 後工程の開始予定日時を考慮するため。
(2)
時間計算区分が「比例」の場合: 工程マスター.所要時間 * 製造.製造指示数
時間計算区分が「一定」の場合: 工程マスター.所要時間
問2
プロンプト
問1の問題文を元に、設問 2の(1) (2) (3)の回答を作成してください。
問題はこちら
設問 2 〔システム統合の方針〕について答えよ。
(1) 本文中の下線①で在庫管理有無フラグの値を設定する規則を、30 字以内で答えよ。
(2) 本文中の下線②で主キーを追加するファイルを二つ答えよ。 また、追加が必要になった B 社の要件を、30 字以内で答えよ。
(3) B 社が、合併後に統合後のシステムを利用して原材料調達業務を実施するに当たり、仕入先に依頼する業務手続上の変更点は何か。 25 字以内で答えよ。
Gemini 1.5 flashの回答は以下のとおり
設問2の回答
(1) B社の製品は在庫管理を行わないため、「無」を設定する。
(2)
ファイル名 : 生産計画、製造
B社の要件 : 1日に同一製品を複数回製造するため、製造開始予定時刻を追加する必要がある。
(3) A社が定めた様式の発注書を電子メールで送信する。
問3
プロンプト
問1の問題文を元に、設問3の(1) (2) の回答を作成してください。
問題はこちら
設問 3 〔システム稼働後の評価〕について答えよ。
(1) 本文中の下線③のある作業とは何か。 40 字以内で答えよ。
(2) 本社管理部門の業務はどのように改善されたか。 その内容を 30 字以内で答えよ。
Gemini 1.5 flashの回答は以下のとおり
設問3の回答
(1) 月末に記録表を参照して、製造実績と投入実績をまとめて入力する作業。
(2) 管理指標値を製造の翌日に確認できるようになった。
ちょうど模範解答が公開されていたので、そちらを参照したところ回答は以下のとおり
設問2は若干怪しい解答ですが、概ね合っているようです。そもそも解答欄のフォーマットを指定せずにgGeminiには質問しているので、より正確な回答を期待するのなら詳細な解答条件等を指定する必要がありそうです。
＊ちなみにこの後モデルをgemini1.5 proに変更して同じ質問をしたところほぼ同じ解答が返ってきました。
問題文を元に新しい設問を作成させる
ためしに、新しい問題を作成させたところ、
問1の出題の趣旨を元に、問1の問題文を参考にして新しい問題とその解答例を作成してください。
以下のような文章が生成されました。とても良い設問ではないかと思いました。
新しい問題
A社の生産管理システムでは、製造指示データに基づいて原材料や仕掛品の在庫状況をリアルタイムに更新する機能の検討が始まりました。この新機能が追加されると、製造指示の開始実績日時に入力があったタイミングで在庫数が更新されます。
(1) この新機能を開発するにあたり、既存のA社の生産管理システムのファイルに対して、新たに属性の追加が必要となる可能性があります。追加が必要となる可能性がある属性を1つ挙げ、その属性の追加が必要となる理由を説明しなさい。
(2) この新機能によって、A社の製造現場ではどのようなメリットがあると考えられますか。具体的な例を挙げて説明しなさい。
解答例
(1)
追加が必要となる可能性のある属性: 在庫引当数 (INT) 、投入予定日時 (DATETIME)など
理由:
製造指示の開始実績日時に入力があったタイミングで在庫を減らす場合、製造指示が出された段階で在庫を確保しておく必要があります。 在庫引当数を設けることで、製造指示ごとに必要な在庫を確保し、他の製造指示との競合を防ぐことができます。
または、投入指示にも開始予定日時があるように、投入にも開始予定日時を持たせることで、投入量の管理をするようにシステムを変更する必要がある。
(2)
メリット: リアルタイムな在庫状況の把握による、製造現場における以下の改善
欠品の予防: 在庫状況をリアルタイムに把握することで、原材料や仕掛品の欠品を事前に予測し、発注を早めるなどの対策が可能になる。
仕掛品滞留の防止: 工程間の在庫状況を把握することで、特定の工程に仕掛品が滞留することを防ぎ、スムーズな生産が可能になる。
納期の遵守: 正確な在庫状況に基づいた製造計画の立案と調整が可能になり、納期の遵守率向上に繋がる。
具体的な例:
従来のシステムでは、在庫データの更新は各工程の終了時に行われていたため、製造指示が出された後に在庫が不足していることに気付く場合がありました。この新機能により、製造指示の開始時に在庫が確保されるため、欠品による製造の遅延を防ぎ、顧客への納期遅延リスクを低減できます。
所感と改善
今回は、Google CloudのVertex AIが提供するマルチモーダルかつチャット形式のマルチターンというUIをそのまま利用しています。この場合だと、基本的にはスレッドをつくり最初にPDFファイルを
読み込ませて、それを知識ベースとしてやり取りを続けることになるため、インプット、アウトプットの文字数が多くなってしまい、性能、課金とも課題が残ります。（とはいえ課金額はVertexAIのみだとこれだけやりとりしても20円未満でしたが）
また適切なプロンプト（指示）に関しては、今回のように毎回インタラクティブにやり取りをしながら答えを探っていくのは利用者にとって大変ですし、誰しもができるような方法ではありません。利用者の負荷を下げるためには、あらかじめシステムの中にこういった指示をするプロンプトを仕込む方法が有効だと考えられます。つまりLLMにただ回答させるチャットアプリを用意するだけでは不十分であり、UXをしっかり考慮したアプリケーションを提供するためには、UIはもちろん、その裏側のLLMの能力を引き出すための適切なプロンプトの仕込み、またLLMを呼び出す順序や結果の再加工などを考慮するバックエンドの仕組みも重要であると言えます。
また、生成AIを活用するためには、適切なプロンプト（指示）と、生成された結果を検証し正誤判定できる知識が必要です。こちらに関しては、生成AIという技術の活用以前の問題ですので、学習を通じて、または有識者や一緒に学ぶ友人や同僚の力を借りながら問題に対する正解を考える他ありません。ただし今回に関しては当記事執筆途中にIPAより解答例が開示されたので、答え合わせをするのは楽にはなりましたが。
さいごに
生成AIをうまく活用するためにはやはり、プロンプトの工夫と試行錯誤が重要なことがわかりました。
このような方法を使うことで、当初の目的である効率的な学習はもちろんのこと、通常業務において生成AIの活用が想定されるようなユースケース、例えば要件定義書がインプットとしてあったとしてそれを素早く図式化したり、要件の確からしさをチェックしたり、ということにも流用できるのではないかと思いました。また視点を変えてみると、この方法で色々とやってみると、生成AIと効率的にやり取りして適切なアウトプットを得るためには、インプットとなる要件定義書の書き方の最適化やその品質が重要である、といった勘所みたいなことが見えてくるのではと思います。
Discussion