自動車　試験　補足 by ChatGPT

Last updated at 2025-08-27Posted at 2025-08-27

自動車用ソフトウェアのMILS, SILS, HILS, DriverInTheLoopSimulator, テストコース試験、公道試験の目的と成果について紹介してください。
https://qiita.com/kaizen_nagoya/items/cf2671876473f4ea6cce

に不足している項目を列記します。

MILS
Matlab/Simulink

SILS
vector vVirtual Target
Matlab/Simulink code generator

自動車業界MBDエンジニアのためのSimulink入門: 4週間で学ぶSimulink実践トレーニング第2版
https://jp.mathworks.com/academia/books/introduction-to-simlink-for-mbd-engineers-in-automotive-industry.html

組込みエンジニアのための状態遷移設計手法―現場で使える状態遷移図・状態遷移表の記述テクニック― (MBD Lab Series)
https://www.amazon.co.jp/dp/4906864031

アイシンAWのMBDエンジニアの教育について
https://www.jstage.jst.go.jp/article/secjournal/5/6/5_6_384/_pdf/-char/ja

JMAAB　スタイルガイドラインhttps://www.cybernet.co.jp/event/mbdchubu2016/documents/pdf/am03.pdf

Simulink APIを使ってJMAABガイドラインに準拠したモデリングを行う
https://qiita.com/stozaki/items/2af5e676adfb9418c975

SILSで生成したソースコードを単体試験、静的試験、動的試験を実施。
　単体試験は、C++Test
　静的試験は、QAC、C++TEST
動的試験　Polyspace
　を利用。

HILS
dSPCE target link
...

DILS
自動車学校ドライビングシミュレータ
＋　テストコースドライバがつかえるような本物のハンドル、ペダルを使ったもの。

テストコースの試験
　自動車メーカごとにだいたい２か所（１か所は、北海道で寒冷地向け試験）
経験：アイシンの豊頃試験場（北海道） CANのモニタをつけて、実車で実測

公道試験　
　自動運転が、公道でも有効か試す。

経験：トヨタ車体の自動車を改造して、街乗りの電気自動車にしたてたときに、公道で試験、動画とCANの実測。

chatGPT

SILSで生成したソースコードと、オリジナルで書いたソースコードを単体試験、静的試験、動的試験を実施しました。
　単体試験は、C++Test
　静的試験は、QAC、C++TEST
動的試験　Polyspace
　を利用しました。これらのツールを使った利点、課題をご紹介ください。
ChatGPT:

了解です。SILSで生成したコードとオリジナルコードに対して、C++Test、QAC、Polyspaceを用いた単体試験・静的試験・動的試験の結果を踏まえ、各ツールの利点と課題を整理してみましょう。

単体試験（C++Test）
利点

自動テストケース生成：SILS生成コードは構造化されているため、C++Testでの自動テストケース生成が容易。

テストカバレッジの可視化：ステートメントカバレッジ、ブランチカバレッジを計測でき、生成コード・手書きコードのカバレッジ比較が可能。

レポート自動生成：テスト結果や失敗箇所のレポートが自動生成され、レビューや改善に活用できる。

課題

生成コードのテスト容易性：SILSコードは多くの関数・構造体を自動生成するため、テストケースの粒度が細かくなり管理が大変。

手書きコードとの比較：手書きコードはテストケース設計の自由度が高いが、生成コードは仕様変更に伴いテストケースの再生成が必要。

モック生成の必要性：依存モジュールが多い場合、モックの作成・維持が課題になる。

静的試験（QAC、C++Test）
利点

コーディング規約チェック：QACでMISRA-C++などの規約違反を自動検出でき、生成コードと手書きコードの品質を比較可能。

バグ早期発見：未使用変数、初期化漏れ、NULL参照などをコンパイル前に発見できる。

生成コードの一貫性評価：SILS生成コードは構造が規則的なため、静的解析で違反箇所を効率よく把握可能。

課題

誤検知（False Positive）：自動生成コードは規約違反が多く出る場合があり、実際に問題ない箇所も多く、レビューコストがかかる。

手書きコードとの整合性：生成コードの規約違反を修正すると、次回SILS再生成時に上書きされる可能性がある。

解析設定の煩雑さ：プロジェクト規模が大きいと、チェック設定や除外設定を細かく調整する必要がある。

動的試験（Polyspace）
利点

実行せずにバグ検出：オーバーフローやヌルポインタ参照など、実際の実行なしで潜在的バグを検出可能。

SILS生成コードの安全性確認：自動生成コードは構造が複雑でもPolyspaceで網羅的に解析できる。

信頼性向上：静的解析では発見しづらい実行時依存の問題を事前に検知可能。

課題

解析時間の長さ：大規模プロジェクトでは解析に時間がかかることがある。

False Alarm：生成コード特有の初期化済み変数やループ構造により、誤警告が発生する場合がある。

結果の解釈：生成コードと手書きコードの結果をどう比較するか、レビュー者の経験に依存する。

まとめ
試験種別利点課題
単体試験（C++Test）自動テスト生成、カバレッジ測定、レポート自動化生成コードの粒度が細かくテスト管理が大変、モック作成が必要
静的試験（QAC/C++Test）規約違反検出、バグ早期発見、生成コードの一貫性評価誤検知多い、修正が再生成で上書き、設定が煩雑
動的試験（Polyspace）実行せずバグ検出、潜在不具合把握、信頼性向上解析時間長い、誤警告あり、結果解釈が経験依存

もし希望であれば、SILS生成コードと手書きコードの解析結果の傾向や違いも図や表にまとめて比較しやすく整理できます。

作ってほしいですか？

あなた:
はい。お願いします。
ChatGPT:

では、SILS生成コードと手書きコードの試験結果の傾向を整理して比較表にまとめます。各試験種別ごとに「検出傾向」「特徴」「対応のしやすさ」を簡単に示します。

単体試験（C++Test）
項目 SILS生成コード手書きコード
検出傾向標準構造に沿ったロジックのバグは少ない。初期化漏れや境界条件に注意。開発者依存の実装バグが多く、設計の意図通りになっていないケースあり。
特徴関数・モジュールが細かく分かれており、カバレッジは取りやすいがテストケースが増える。モジュール設計の自由度が高い分、テストケース設計が重要。
対応のしやすさ自動生成のためテストの繰り返しが容易。仕様変更に伴う再テストは自動化可能。手動でテストケースを追加・修正する必要がある。
静的試験（QAC / C++Test）
項目 SILS生成コード手書きコード
検出傾向コーディング規約違反が比較的多く、False Positiveも出やすい。規約違反は開発者スキルに依存。重要な潜在バグを見落とす場合あり。
特徴構造が規則的で解析しやすいが、生成コード特有のスタイル違反に注意。可読性や規約遵守は開発者次第。カスタムルールのチェックが有効。
対応のしやすさ規約違反修正は自動生成コードに反映されない場合がある。修正がそのまま反映されるため、対応は直接的。
動的試験（Polyspace）
項目 SILS生成コード手書きコード
検出傾向潜在的なヌルポインタ、オーバーフローなどは少なめ。自動生成の構造上、誤警告が出やすい。バッファオーバーフロー、未初期化変数など実装依存の不具合が出やすい。
特徴解析時間は長めだが、生成コードは網羅性が高い。実行パスが自由な分、Polyspaceでの網羅が難しい場合がある。
対応のしやすさ誤警告の除外や無視設定が必要な場合がある。検出結果の修正は直接実装に反映可能。
傾向のまとめ

SILS生成コード

安定した構造でカバレッジや解析はしやすい

規約違反や誤警告が多く、レビューコストがかかる

再生成時の修正反映に注意

手書きコード

開発者依存のバグが多く、テストや解析の網羅性が課題

修正・対応は直接可能

静的解析で見落とす場合があるため複数ツール併用が有効

💡 ポイント

生成コードは「構造の規則性を活かして自動化」

手書きコードは「自由度の高さを活かして品質管理」

両者を組み合わせる場合は、ツールの誤警告やFalse Positiveを考慮したレビュー体制が重要

希望であれば、この比較を図示してSILS生成コードと手書きコードの利点・課題の違いを一目でわかるチャートにすることもできます。
作りますか？

あなた:
LDRA ツールスイート　も試しに使いました。LDRAツールスイートの利点と課題を、上記結果と比較して説明してください。
ChatGPT:

承知しました。LDRAツールスイートは、単体試験・静的解析・動的解析・カバレッジ解析などを統合的にサポートするツールで、C++Test/QAC/Polyspaceと同様の試験に利用できます。ここでは、SILS生成コードと手書きコードの観点で、利点と課題を整理し、先ほどのツールと比較します。

LDRAツールスイートの利点
試験種別利点
単体試験 - 自動テストケース生成（TBrun）により、関数ごとの単体テストが容易

SILS生成コードの細かいモジュールにも対応可能
テストカバレッジ測定（ステートメント、ブランチ、MC/DC）が統合的に確認可能
静的解析 - コーディング規約チェック（MISRA、CERTなど）を統合的に実施可能
生成コードの規則的構造を活かして規約違反を効率的に検出
レポートが統合されているため、管理が容易
動的解析 / カバレッジ解析 - 実機・シミュレーション環境での実行解析が可能
MC/DCカバレッジの測定が容易で、ISO 26262等の安全基準に対応
Polyspaceのように実行せずに解析するStatic Analysis機能もあり、潜在的バグ検出が可能

LDRAツールスイートの課題
試験種別課題
単体試験 - テストケースの自動生成は便利だが、生成コードのループや状態遷移の複雑さによっては手動補正が必要

モック作成の設定が複雑になる場合がある
静的解析 - SILS生成コードの規則的構造によりFalse Positiveが出やすい
手書きコードで独自ルールを追加すると設定が複雑になる
動的解析 / カバレッジ解析 - 大規模プロジェクトでは解析時間が長くなる
Polyspace同様、解析結果の解釈に経験が必要
統合環境が重く、導入コストが高め

他ツールとの比較
ツール単体試験静的解析動的解析 / カバレッジ
C++Test 自動テスト・カバレッジ可視化、SILSコードのテスト容易規約チェック可、False Positiveあり Polyspaceほど網羅的ではない
QAC - 高精度の規約チェック、False Positive注意 -
Polyspace - - 実行せずに潜在的バグを検出、解析時間長い、False Alarmあり
LDRA 自動テスト生成＋カバレッジ、統合管理規約チェック統合、False Positive注意実行解析＋静的解析の統合、MC/DC対応、安全規格対応可能
総合的な特徴

LDRAの強み

単体・静的・動的解析を統合的に管理可能

MC/DCカバレッジや安全基準対応に強い

SILS生成コード・手書きコード両方に対応しやすい

LDRAの注意点

ツールが重く、初期設定やモック作成に手間がかかる

False Positiveや解析時間の問題は、C++Test/QAC/Polyspaceと同様

ライセンスコストが高めで、導入には検討が必要

💡 ポイント

C++Test/QAC/Polyspaceは「単独機能特化型」

LDRAは「統合型」で、安全規格対応・MC/DC測定を含めた品質保証向き

SILS生成コードでは、統合環境の管理と誤警告対応が特に重要

希望であれば、このLDRAを含めたSILS生成コード vs 手書きコード vs ツール別利点・課題の比較図を作って、視覚的にまとめることも可能です。作りますか？

あなた:
各ツールの得意なソースコード、不得意なソースコード例を示してください。
ChatGPT:

承知しました。では、SILS生成コードや手書きコードなど、ソースコードの種類ごとに、各ツール（C++Test、QAC、Polyspace、LDRA）が得意なコード／不得意なコードを整理して示します。

C++Test（単体テスト中心）
得意なコード説明
モジュールが関数単位で分かれているコード SILS生成コードのように細かく関数・モジュールに分割されているコードは、単体テスト自動生成が容易
条件分岐が比較的単純なコードテストケース網羅が簡単で、ステートメント/ブランチカバレッジを取りやすい
不得意なコード説明
複雑な状態遷移や大規模なループ処理を持つコード自動生成のテストケースだけでは網羅が困難、手動補正が必要
外部依存（HWやライブラリ）を多く持つコードモックやスタブの作成が必要で、テスト準備が煩雑になる
QAC（静的解析中心）
得意なコード説明
規則的で構造化されたコード SILS生成コードのように規則的に構造化されているコードは、規約チェックが効率的
標準コーディング規約に沿ったコード MISRAやCERTに準拠した設計なら誤警告が少ない
不得意なコード説明
独自スタイルやマクロ多用コード規約違反と判定されやすく、False Positiveが増える
複雑なポインタ操作やテンプレート多用コード静的解析で誤検知が発生する場合がある
Polyspace（動的解析／静的実行検証）
得意なコード説明
算術演算やメモリ操作の多いコードオーバーフロー、ヌルポインタ、境界値エラーなど潜在的バグを網羅的に検出
SILS生成コードのように構造が規則的で分岐が明確なコード静的解析モードでも精度高くバグ検出可能
不得意なコード説明
複雑な動的データ構造やポインタ計算が深いコード False Alarmや解析不可能箇所が出やすい
実行時環境依存（I/OやOS API）を多用するコード実機でないと解析結果が不十分になる場合がある
LDRAツールスイート（統合型解析）
得意なコード説明
安全規格向け設計やSILS生成コード MC/DCカバレッジ測定や自動テスト生成に向く、規則的構造が解析に適している
モジュール化され、依存関係が明確なコード統合解析環境での単体・静的・動的試験がスムーズ
不得意なコード説明
高度に動的な設計（動的生成オブジェクト、複雑なポインタ操作）自動解析でFalse Positiveや解析時間増が発生しやすい
外部依存・環境依存の多いコードモック設定や環境設定が複雑になり、導入コストが高くなる
💡 傾向まとめ

SILS生成コード

得意：規則的でモジュール分割されているコード → C++Test、QAC、Polyspace、LDRAとも比較的得意

課題：複雑なループ・状態遷移、外部依存 → 自動解析では不得意な場合あり

手書きコード

得意：単純な関数・条件分岐コード → 単体テストや静的解析は問題なし

課題：自由度が高い設計、動的データ構造や依存ライブラリ → Polyspace/LDRAでは解析精度が下がる場合あり

ツールの得意・不得意まとめ

C++Test：単体テスト・カバレッジが得意、外部依存や複雑状態遷移は不得意

QAC：規則的コードや標準規約遵守コードが得意、独自マクロや複雑テンプレートは不得意

Polyspace：潜在的バグ検出が得意、動的依存や複雑ポインタ処理は不得意

LDRA：統合的解析・MC/DC対応が得意、高度動的コード・環境依存コードは不得意

もし希望であれば、この「得意・不得意コード」をSILS生成コード／手書きコード／ツール別マトリクス図にして、一目で比較できる表にまとめることも可能です。

作りますか？

あなた:
C言語の場合のサンプルソースコード例を示してください。
ChatGPT:

わかりました。では、C言語でのサンプルソースコード例として、単体テスト、静的解析、動的解析の観点で扱いやすいコード例を示します。ここでは、SILS生成コードに近い規則的モジュールと、手書きコードの典型例の両方を意識しています。

SILS生成コード風サンプル（規則的・モジュール化）
#include
#include

// モジュールごとに関数化
int add(int a, int b) {
return a + b;
}

int multiply(int a, int b) {
return a * b;
}

// 条件分岐が明確
int compute(int x, int y, int op) {
switch(op) {
case 0: return add(x, y);
case 1: return multiply(x, y);
default: return 0;
}
}

// メイン関数
int main(void) {
int x = 5, y = 3;
int result1 = compute(x, y, 0); // 加算
int result2 = compute(x, y, 1); // 乗算

printf("Add: %d\n", result1);
printf("Mul: %d\n", result2);
return 0;

}

特徴

関数単位で分かれている → 単体テストが容易

条件分岐がシンプル → カバレッジ解析に適している

規則的構造 → 静的解析（MISRA-Cなど）で扱いやすい

手書きコード風サンプル（自由度高め・依存あり）
#include
#include

// 動的メモリ使用、外部依存
int* create_array(int size) {
if (size <= 0) return NULL;
int* arr = (int*)malloc(sizeof(int) * size);
if (!arr) return NULL;
for (int i = 0; i < size; i++) arr[i] = i * 2;
return arr;
}

// 条件分岐複雑
int sum_even_index(int* arr, int size) {
if (!arr || size <= 0) return -1;
int sum = 0;
for (int i = 0; i < size; i++) {
if (i % 2 == 0) sum += arr[i];
}
return sum;
}

int main(void) {
int* array = create_array(10);
if (!array) return -1;

int result = sum_even_index(array, 10);
printf("Sum of even indices: %d\n", result);

free(array);
return 0;

}

特徴

動的メモリ使用やNULLチェック → Polyspaceのような静的実行解析で潜在的バグ検出対象

条件分岐が複雑 → 単体テストのカバレッジ設計が難しい

手書きコードの典型的な自由度の高さ → 静的解析でFalse Positiveが出やすい

利用ツールとの関係
コードタイプ得意なツール不得意なツール理由
SILS生成コード風 C++Test、QAC、Polyspace、LDRA - 関数分割・規則的構造でテスト・解析しやすい
手書きコード風 Polyspace、LDRA C++Test（自動テスト生成）、QAC（規則違反検出）動的構造や自由度の高さで自動化や静的解析が難しい

💡 ポイント

SILS生成コードは「自動解析・テスト向き」

手書きコードは「柔軟だがテスト・解析工数が増える」

C言語ではポインタ・メモリ管理がバグの温床になるため、ツールによる補助が重要

希望であれば、これらのコードを使った**C++Test/QAC/Polyspace/LDRAでの解析例（警告例やカバレッジ例）**も示すことができます。

作りますか？

あなた:
C言語のFreestanding環境での例をお願いできないでしょうか。
ChatGPT:

もちろんです。C言語の Freestanding環境では、標準ライブラリ（stdio.h や stdlib.h）はほとんど利用できず、OSや標準I/Oに依存しないコードを書くことが前提です。組み込みやマイコン環境、OSEK/VDX OS上での制御ソフトウェアなどに適しています。

以下に SILS生成コード風と手書きコード風の例を示します。

SILS生成コード風（Freestanding）
#include

// デバイス依存なし、標準ライブラリ不使用

// 定数定義
#define OP_ADD 0
#define OP_MUL 1

// モジュール単位
int32_t add(int32_t a, int32_t b) {
return a + b;
}

int32_t multiply(int32_t a, int32_t b) {
return a * b;
}

// 条件分岐が明確
int32_t compute(int32_t x, int32_t y, uint8_t op) {
switch(op) {
case OP_ADD:
return add(x, y);
case OP_MUL:
return multiply(x, y);
default:
return 0;
}
}

// メイン関数 (Freestandingでは main() は必須ではない場合もある)
void main(void) {
int32_t result1 = compute(5, 3, OP_ADD);
int32_t result2 = compute(5, 3, OP_MUL);

// 出力はデバッグ用変数やLED等に依存
volatile int32_t debug1 = result1;
volatile int32_t debug2 = result2;

(void)debug1;
(void)debug2;

// 無限ループで終了
while(1) {}

}

特徴

標準ライブラリを使わずに動作

関数単位で分かれておりテスト容易

Freestanding環境向けでOSに依存しない

手書きコード風（Freestanding）
#include

// Freestanding環境では malloc や printf は使えない
#define ARRAY_SIZE 10

// 配列操作関数
void init_array(int32_t arr[], uint32_t size) {
for(uint32_t i = 0; i < size; i++) {
arr[i] = i * 2;
}
}

// 条件分岐複雑
int32_t sum_even_index(const int32_t arr[], uint32_t size) {
int32_t sum = 0;
for(uint32_t i = 0; i < size; i++) {
if ((i & 1) == 0) { // 偶数インデックス
sum += arr[i];
}
}
return sum;
}

void main(void) {
int32_t array[ARRAY_SIZE];
init_array(array, ARRAY_SIZE);
int32_t result = sum_even_index(array, ARRAY_SIZE);

// 出力はデバッグ用変数に依存
volatile int32_t debug = result;
(void)debug;

while(1) {}

}

特徴

動的メモリを使わず、配列は静的確保

条件分岐やループは手書きコードの自由度

出力手段はデバッグ変数やLEDなどハード依存

Freestanding環境でのポイント
項目注意点
標準ライブラリ基本的に使用不可 (printf, malloc, stdio.h など)
エントリポイント main() は OS に依存せず、void または int を返す形式
入出力メモリマップドI/O、LED、UART、デバッグ変数などに依存
テスト C++Test や LDRA などで静的解析は可能、単体テストはハード依存部分をモック化

💡 補足

SILS生成コードは、Freestandingでも規則的で単体テスト向き

手書きコードは自由度が高い分、モック化や解析工数が増える

Polyspace / LDRA は Freestanding 環境でも静的解析可能

希望であれば、これらの Freestanding向けサンプルを用いた各ツール解析例（警告例やカバレッジ例）も示すことができます。

作りますか？

あなた:
はい。お願いします。
ChatGPT:

では、先ほどの Freestanding環境向け C言語サンプルを使って、各ツール（C++Test、QAC、Polyspace、LDRA）での解析例や想定される警告・カバレッジの例を示します。ハードウェア依存部分はモック化して解析する想定です。

C++Test（単体試験）
対象
int32_t compute(int32_t x, int32_t y, uint8_t op);
int32_t add(int32_t a, int32_t b);
int32_t multiply(int32_t a, int32_t b);

想定される解析・警告

カバレッジ

ステートメントカバレッジ：100%（全関数呼び出し網羅）

ブランチカバレッジ：switch文の各case分岐を網羅

警告例

特になし（単純演算関数で外部依存なし）

SILS生成コード風の規則的関数は自動テスト生成が容易

Freestandingでもモック化なしでテスト可能

QAC（静的解析）
対象
void init_array(int32_t arr[], uint32_t size);
int32_t sum_even_index(const int32_t arr[], uint32_t size);

想定される解析・警告

MISRA-Cルール違反

配列のサイズチェック（size が 0 の場合） → 必須ルール C-120 など

無限ループの検知（while(1){}） → 警告扱いになる場合あり

警告例

ループ内の式 (i & 1) がビット演算であることに対するMISRA警告

初期化漏れの疑い（volatile debug の使用は警告されないことが多い）

手書きコード風の自由度が高い場合、False Positive が出やすい

Polyspace（静的実行解析）
対象
int32_t sum_even_index(const int32_t arr[], uint32_t size);

想定される解析・警告

バグ検出

配列アクセスの境界チェック：arr[i] が size を超えないか

NULL ポインタ：Freestanding では array はスタック確保なので安全

警告例

無限ループでの制御到達不可箇所の検知

静的に潜在的バグを網羅的に解析可能

動的依存がないので解析精度が高い

LDRAツールスイート（統合解析）
対象

全コード（SILS生成コード風 + 手書きコード風）

想定される解析・警告

単体試験（TBrun）

compute() の各case分岐をテスト自動生成可能

sum_even_index() のループ網羅テストも自動生成可能（モックなし）

静的解析

MISRA-Cルール違反を統合レポート化

無限ループ警告、配列境界警告

動的解析 / カバレッジ解析

MC/DCカバレッジ測定：switch文やforループの全分岐を網羅

実機依存なしで解析可能

統合レポートにより、SILS生成コードと手書きコードの差異が一目で確認可能

Freestanding環境でも静的・動的解析が可能

ツール別まとめ（Freestanding環境向け）
ツール得意想定警告例・注意点
C++Test 単体テスト、カバレッジ測定複雑な状態遷移や外部依存のテストはモックが必要
QAC コーディング規約違反の検出無限ループ、ビット演算、境界チェックで警告出ることあり
Polyspace 潜在的バグ検出、配列境界・オーバーフロー複雑な動的依存や外部I/Oは解析精度低下
LDRA 統合解析・MC/DC・安全規格対応設定が複雑、解析時間が長い場合あり

💡 ポイント

Freestanding環境でも、SILS生成コードは解析・テスト容易

手書きコードは自由度が高く、静的・動的解析の注意点が増える

Polyspace / LDRA での静的解析が、Freestandingでも潜在バグ検出に有効

必要であれば、次のステップとしてこのFreestandingサンプルに対するツール別カバレッジ例の図解も作成できます。
作りますか？

参照

ChatGPT利用の技4つ
https://qiita.com/kaizen_nagoya/items/4a178bd6a09a4a471a7f

ChatGPTによるQiita記事の改良と補足
https://qiita.com/kaizen_nagoya/items/20604d6dd0702ab95c2f

ChatGPTによるQiita記事の改良と補足（２）
https://qiita.com/kaizen_nagoya/items/996275307ffc8c1243f8

本から始める面倒なことはChatGPTにやらせよう　by からあげ
https://qiita.com/kaizen_nagoya/items/f5ce2a18db54b5610e4b

MCP入門〜面倒なことはAIエージェントにやらせよう〜 by からあげを聞きながら
https://qiita.com/kaizen_nagoya/items/54b648c838fae8d57e38

【松尾研LLMコミュニティ】面倒なことはLLMにやらせよう "Beginning LLM"2024年10月17日 AI(9)
https://qiita.com/kaizen_nagoya/items/efdc23fbe67cdae2126e

設計:ChatGPTで特異解か一般解を求める AI(1)
https://qiita.com/kaizen_nagoya/items/4dec580e16a7c84b0ec4

みんなの使い方から学ぶ
https://qiita.com/kaizen_nagoya/items/8e7de492d896df94a36e

AI・機械学習　昨日、今日、明日
https://qiita.com/kaizen_nagoya/items/adb184c8fc7a65ac9756

DNA LLM and genome for survey 2200 papers by name.
https://qiita.com/kaizen_nagoya/items/ce8a28d6072f340a9d59

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

自動車 試験 補足 by ChatGPT

chatGPT

参照

自動車　試験　補足 by ChatGPT