2025年の開発者が知ってる11技能 with ChatGPT

「@rana_kualu 2020年の開発者が知っておくべき11の必須技能」→回答編 → 並べ替え→項目合併(8項目)→内容追記。
https://qiita.com/kaizen_nagoya/items/39e1c69bddb8e608b42b

に追記しようと思いました。最適化とconstexprを検討しました。

ChatGPT

https://qiita.com/kaizen_nagoya/items/39e1c69bddb8e608b42b の2025年版を作ろうと思います。何を追記するとよいでしょうか。

ChatGPT:

2025年版の「2020年の開発者が知っておくべき11の必須技能」の更新に際し、以下の新たな技術やトピックを追記することを検討してみてはいかがでしょうか。
🔧 新たに追記すべき技術・トピック

1. エージェント型AI（Agentic AI）
   従来のAIが人間の指示に従うのに対し、エージェント型AIは自律的に目標達成のための計画を立て、行動します。例えば、カスタマーサービスや製造業の予測メンテナンスなどで活用が進んでいます。開発には透明性や責任ある設計が求められます。
   HBLAB JSC
2. AIガバナンス・プラットフォーム
   AI技術の普及に伴い、その利用を管理・制御する「AIガバナンス・プラットフォーム」の重要性が増しています。このプラットフォームは、AIの倫理的・法的な利用を確保するためのツール群を提供します。
   HBLAB JSC
3. 偽情報セキュリティ
   AIを用いた偽情報の生成や拡散が問題視される中、偽情報を検出・対処するための技術や手法が注目されています。これには、自然言語処理技術やファクトチェックの自動化などが含まれます。
   HBLAB JSC
4. ポスト量子暗号
   量子コンピュータの発展により、従来の暗号技術が破られる可能性が指摘されています。そのため、量子コンピュータに耐性を持つ「ポスト量子暗号」の研究・開発が進められています。
   HBLAB JSC
5. ローコード/ノーコード開発
   プログラミングの知識がなくてもアプリやウェブサイトを作成できるローコードやノーコード開発ツールが普及しています。これにより、非エンジニアでもシステム開発に関与できるようになっています。
   note（ノート）
   🛠️ 既存スキルの再評価と強化
   既存の必須技能に関しても、2025年の技術動向を踏まえて再評価し、強化することが重要です。
   Python：AIやデータ分析の分野で引き続き重要な言語です。
   Git：チーム開発やCI/CDの導入に不可欠なバージョン管理ツールです。
   Docker：コンテナ技術は、マルチクラウド環境やエッジコンピューティングなどでの活用が進んでいます。
   クラウドプラットフォーム（AWS, GCP, Azure）：クラウドサービスの導入・運用スキルは依然として高い需要があります。
   セキュリティ：AIの普及に伴い、セキュリティの重要性が増しています。特に、AIを用いた攻撃への対策や、AIシステムのセキュリティが求められます。

✅ まとめ
2025年の技術動向を反映させることで、現代のエンジニアにとって必要なスキルセットを網羅的に示すことができます。新たな技術の習得と、既存スキルの強化をバランスよく進めることが、キャリアの成長に繋がるでしょう。

ローコード・ノーコード開発は、1986年にプログラムジェネレータジェネレータを作成して市場に出そうとしたことがあります。当時は、お金にならないという理由で発売できませんでした。1986年と2025年の違いはなんでしょうか。

ChatGPT:

なるほど、1986年と2025年のローコード・ノーコード（LC/NC）開発の違いを整理すると、単なる技術の進歩だけでなく、社会環境・市場構造・利用者層の変化も大きく関わっています。ポイントごとに比較してみます。

1. 技術的成熟度
   項目 1986年 2025年
   プログラミング環境 BASICやCOBOLなど限定的 クラウド対応、ブラウザベース、モバイル対応
   GUI設計 簡単なフォーム作成程度 ドラッグ&ドロップで高度なUI・ワークフロー作成可能
   実行環境 単体PCやメインフレーム クラウド、マルチデバイス、マイクロサービス対応
   自動生成の精度 生成コードは限定的、最適化されず 高度に最適化されたコード、API連携やAI補助も可能
   → 1986年は「作れるけど使えない」状態。2025年は「作れてすぐ使える」状態。
2. 市場とユーザーの変化
   項目 1986年 2025年
   ユーザー層 プログラマ中心 非エンジニア（業務担当者、マーケター、管理職）も対象
   市場ニーズ エンタープライズシステムはコスト重視 DX推進、迅速なサービス開発、多様な業務自動化が求められる
   導入コスト 高額・インフラ依存 クラウド型サブスクで初期投資低、拡張容易
   ROIの認識 開発効率より完成度重視 スピード・柔軟性・即応性が評価される
   → 1986年は「お金にならない」と判断されたが、2025年は「即戦力の効率化ツール」として経済価値がある。
3. 技術的補助とエコシステム
   1986年
   プログラム生成は限定的で、テストやデバッグも手作業中心
   他システムとの連携は困難
   2025年
   AIによるコード補完、バグ検出、自動テストが可能
   API連携・クラウドサービスとの統合が容易
   コミュニティやテンプレート、マーケットプレイスが充実
   → 1986年は「技術的孤立」、2025年は「エコシステムに支えられた利用」が可能。
4. 社会的受容
   デジタルリテラシーの向上により、非エンジニアでも開発ツールを使える
   DX（デジタルトランスフォーメーション）の推進で、スピード優先の開発文化が定着
   → 1986年は「限定的な専門家向け」、2025年は「一般ユーザーも活用可能」と環境が整備。

結論
1986年にローコード・ノーコードが商用化できなかったのは、技術力・市場・社会受容の三重の制約があったためです。2025年ではこれらの制約がほぼ解消されており、誰でも短期間で価値を生み出せる環境が整っていることが大きな違いです。
希望であれば、1986年型の「プログラムジェネレータ」と2025年型ローコードツールの比較図を作って、視覚的に違いを示すこともできます。作りましょうか？

最適化の側面はその通りだと思います。1986年と2025年の最適化の違いを７つ以上の視点でご説明ください。

ChatGPT:

もちろんです。1986年と2025年のローコード・ノーコード（LC/NC）開発における最適化の違いを、7つ以上の視点で整理すると以下の通りです。単なるコード生成ではなく、全体システムの効率化・品質向上に関わる要素を含めています。

1. コード生成精度
   1986年：生成されるコードは単純で、冗長かつ最適化されていない。手動修正が必須。
   2025年：生成コードはコンパイラ最適化やAI補助により、高速かつ効率的。不要な処理が省かれ、メモリ効率も高い。
2. アルゴリズムの選択
   1986年：固定的・簡単なアルゴリズムしか選択できず、問題に最適化されていない。
   2025年：AIやテンプレートにより、用途やデータ量に応じて最適なアルゴリズムを自動選択可能。
3. データ構造の最適化
   1986年：配列やリストなど単純構造のみで、スケーラビリティに弱い。
   2025年：動的配列、ツリーマップ、ハッシュテーブルなどを自動選択・利用し、処理効率を向上。
4. リソース管理（メモリ・CPU）
   1986年：生成コードはリソース消費が大きく、最小化されない。
   2025年：ランタイムやコンパイラ最適化により、メモリ使用量・CPU負荷を最小化。
5. 並列処理・非同期処理
   1986年：ほぼ単一スレッドで、同時処理や非同期処理はほぼ不可能。
   2025年：マルチスレッド、非同期I/O、クラウド分散処理を自動活用できる。
6. ユーザー操作の効率化
   1986年：GUIは基本的で、ユーザー入力やワークフローの最適化はほぼ手作業。
   2025年：ドラッグ&ドロップや自動フォーム補完、AIによるワークフロー提案で効率化。
7. テスト・デバッグの最適化
   1986年：生成コードのバグ検出は手動、最適化も困難。
   2025年：自動テスト生成、AIによるバグ検出・コード改善提案でテスト効率が高い。
8. 外部連携・API最適化
   1986年：外部システムとの連携は手動コーディングが必要で、最適化されない。
   2025年：APIやクラウドサービスとの接続はテンプレート化され、自動最適化される。
9. デプロイ・運用の最適化
   1986年：生成コードは単体PC用で、デプロイ効率は低い。
   2025年：クラウド、コンテナ、サーバレスに対応し、最適なリソース割当てやスケーリングが可能。

✅ 総括
1986年はコード生成自体が目的で、最適化はほとんど考慮されていませんでした。
2025年は生成コードの効率・品質・運用全体を最適化することが前提になっており、AIやクラウドの力で多層的に最適化が実現されています。
希望であれば、これら9つの視点を**「1986 vs 2025」対比表**にして、論文やQiita記事用に整理することもできます。作りますか？

はい。

ChatGPT:

では、1986年と2025年のローコード・ノーコードにおける最適化の違いを、対比表として整理しました。Qiita記事や資料にそのまま使える形式です。
視点 1986年 2025年
コード生成精度 単純で冗長、手動修正必須 AI補助やコンパイラ最適化により高速・効率的
アルゴリズム選択 固定的・簡単なアルゴリズムのみ 用途・データ量に応じて最適なアルゴリズムを自動選択
データ構造最適化 配列やリストなど単純構造 ツリーマップ、ハッシュテーブルなど自動選択可能
リソース管理（メモリ・CPU） リソース消費大、最小化されない ランタイム・コンパイラ最適化で消費最小化
並列・非同期処理 ほぼ単一スレッド マルチスレッド、非同期I/O、クラウド分散処理を活用
ユーザー操作効率化 基本GUI、手作業中心 ドラッグ&ドロップ、AIワークフロー提案で効率化
テスト・デバッグ 手動でバグ検出・修正 自動テスト生成、AIによるバグ検出・改善提案
外部連携・API最適化 手動コーディング、非効率 API接続・クラウド連携は自動最適化
デプロイ・運用 単体PC向け、効率低 クラウド・コンテナ・サーバレスで自動スケーリング・最適割当
💡 補足ポイント
1986年は「作れることが目的」で、最適化はほぼ考慮されていません。
2025年は「生成から運用まで最適化」が前提で、AI・クラウド・自動化ツールが多層的に効率化を支えています。
希望であれば、この表に**「図解で視覚化した対比」**を追加して、1986年と2025年の最適化の進化を一目で理解できるようにすることもできます。作りますか？

コンパイラ最適化の技術的な特徴を７つ以上ご紹介ください。

ChatGPT:

もちろんです。コンパイラ最適化は、生成されたコードの実行効率やサイズ、消費リソースを改善する技術群で、1986年と2025年の差にも直結します。技術的な特徴を7つ以上整理すると以下の通りです。

1. ループ最適化（Loop Optimization）
   ループの展開（Loop Unrolling）やループ分割により、分岐や条件判定を減らして高速化。
   ループ内で定数計算や不変式を外に出す（Loop-Invariant Code Motion）ことで無駄な計算を削減。
2. デッドコード削除（Dead Code Elimination）
   実行されないコードや結果が使われない計算を削除。
   コードサイズの縮小とCPUキャッシュ効率向上に寄与。
3. 定数畳み込み（Constant Folding）
   コンパイル時に定数計算を行い、実行時の負荷を削減。
   例：x = 2 + 3; → x = 5;
4. 関数インライン化（Function Inlining）
   小さな関数を呼び出し元に展開し、関数呼び出しのオーバーヘッドを削減。
   再帰関数や大きな関数では逆効果になる場合もあるため、最適化戦略が重要。
5. レジスタ割り当て最適化（Register Allocation）
   変数や計算結果をCPUレジスタに効率的に配置し、メモリアクセスを最小化。
   特にループや計算量の多い処理で大幅な性能向上。
6. 命令スケジューリング（Instruction Scheduling）
   CPUパイプラインやスーパースカラー処理を考慮し、命令の順序を再配置して並列実行を最大化。
   分岐予測ミスやパイプラインストールを減らす。
7. メモリアクセス最適化（Memory Optimization）
   キャッシュ効率の向上のためにデータアクセス順序や構造体配置を最適化。
   配列のストライドアクセスやメモリアライメントを改善。
8. 共通部分式削除（Common Subexpression Elimination）
   同じ計算を複数回行わないように一度だけ計算し、結果を再利用。
   例：y = ab + c; z = ab + d; → t = a*b; y = t + c; z = t + d;
9. 分岐予測最適化（Branch Prediction Optimization）
   条件分岐の可能性が高い方に処理を寄せて、CPUの分岐予測ミスを減らす。
   スマートフォンやサーバなどで実行性能に直結。
10. ベクトル化（Vectorization / SIMD最適化）
    データ並列処理をSIMD命令でまとめて実行。
    配列計算や画像処理、AI演算で大幅な高速化を実現。

💡 補足
これらの最適化は単独で使われることもありますが、ほとんどの場合複合的に適用されます。
1986年では一部（ループ展開や定数畳み込みなど）しかできず、2025年ではAI補助や高度な解析によりほぼ自動で最適化されます。
希望であれば、これらの最適化技術を**「1986年 vs 2025年」対応表」**として整理し、ローコード・ノーコード生成コードの性能差を明確化することもできます。作りますか？

具体的にプログラミング言語のソースでご紹介ください。

ChatGPT:

もちろんです。コンパイラ最適化の具体例を、簡単な**C言語やPython（擬似的に示す）**で示します。1986年型と2025年型の最適化の違いがイメージしやすくなります。

1. ループ展開（Loop Unrolling）
   元のコード
   // 1986年：単純なループ
   for (int i = 0; i < 4; i++) {
   a[i] = a[i] + 1;
   }
   最適化後（2025年型）
   // ループ展開で分岐・計算オーバーヘッド削減
   a[0] = a[0] + 1;
   a[1] = a[1] + 1;
   a[2] = a[2] + 1;
   a[3] = a[3] + 1;
2. 定数畳み込み（Constant Folding）
   元のコード
   int x = 2 + 3 * 4;
   最適化後（コンパイル時に計算）
   int x = 14; // 定数畳み込み
3. 共通部分式削除（Common Subexpression Elimination）
   元のコード
   int y = ab + c;
   int z = ab + d;
   最適化後
   int t = a * b;
   int y = t + c;
   int z = t + d;
4. 関数インライン化（Function Inlining）
   元の関数
   int square(int x) { return x * x; }

int main() {
int a = square(5);
}
最適化後（インライン化）
int main() {
int a = 5 * 5; // 関数呼び出しのオーバーヘッドを削減
}
5. ベクトル化（SIMD）
元のループ
for (int i = 0; i < 4; i++) {
c[i] = a[i] + b[i];
}
最適化後（SIMDベクトル化）
#include
__m128 va = _mm_loadu_ps(a);
__m128 vb = _mm_loadu_ps(b);
__m128 vc = _mm_add_ps(va, vb);
_mm_storeu_ps(c, vc);
4要素を同時に加算、CPU命令1回で処理。
6. デッドコード削除（Dead Code Elimination）
元のコード
int x = 10;
int y = x + 5; // yは使われない
最適化後
int x = 10; // yの計算は削除
7. ループ不変式の外出し（Loop-Invariant Code Motion）
元のコード
for (int i = 0; i < n; i++) {
a[i] = i * (x + y); // x + yは毎回計算
}
最適化後
int tmp = x + y;
for (int i = 0; i < n; i++) {
a[i] = i * tmp; // 無駄な計算削減
}

💡 補足
1986年では、これらの最適化はほぼ手動で行わなければならず、ローコード生成でもコードの効率は低い。
2025年では、コンパイラやAI補助ツールにより自動で適用され、ローコード・ノーコードでも効率的なコード生成が可能です。
希望であれば、この例をもとに**「1986年型コード vs 2025年型コード」のフル対比サンプル」**としてまとめ、Qiita記事用に掲載できる形に整えることもできます。作りますか？

C++のConstexprは、最適化に役立ちますか。

ChatGPT:

はい、C++の constexpr は最適化に非常に役立ちます。技術的には「コンパイル時評価」を保証する機能で、コンパイラ最適化の一環として以下のようなメリットがあります。

1. 定数畳み込みの強制
   通常の定数畳み込み（Constant Folding）はコンパイラの裁量ですが、constexpr は必ずコンパイル時に評価されることを保証します。
   constexpr int square(int x) { return x * x; }
   int y = square(5); // コンパイル時に 25 に置き換えられる
   実行時の計算が不要になり、CPU負荷を削減。
2. ループ不変式の外出し（Loop-Invariant Code Motion）との相性
   constexpr を使えば、ループ内の計算をコンパイル時に評価可能。
   constexpr int factor = 3;
   for (int i = 0; i < n; ++i) {
   arr[i] = i * factor; // factorはコンパイル時定数
   }
   実行時に計算されるのは i * factor のみ。
3. 配列サイズやメモリ割当の最適化
   constexpr を使うと、配列サイズや構造体のメンバオフセットなどをコンパイル時に決定可能。
   constexpr size_t N = 1024;
   int arr[N]; // コンパイル時にサイズ確定
   メモリ割当やキャッシュ配置を最適化しやすくなる。
4. 関数インライン化との相乗効果
   constexpr 関数は必然的にコンパイル時評価されるため、関数呼び出しオーバーヘッドも回避。
   constexpr int sum(int a, int b) { return a + b; }
   int total = sum(2,3); // 実行時の関数呼び出しなし
5. 条件分岐の簡略化
   constexpr if と組み合わせると、コンパイル時に条件を評価して不要な分岐を削除。
   template
   void f() {
   if constexpr (N > 0) {
   // N > 0 の場合のみコンパイルされる
   }
   }
   実行時の条件判定が不要になり、分岐予測コストを削減。

✅ まとめ
constexpr は コンパイル時評価を保証することで、実行時コストを削減 する最適化ツールです。
ループ最適化、関数インライン化、定数畳み込み、分岐削除、メモリ配置など、複数の最適化に直接貢献します。
1986年にはこうした「コンパイル時保証」は存在せず、2025年のC++環境ではローコード・ノーコード生成でも利用可能です。
希望であれば、constexpr を活用した1986年型 vs 2025年型コードの最適化例を実際にC++で書いて比較することもできます。作りますか？

はい。

ChatGPT:

では、constexpr を活用して 1986年型（最適化なし）と2025年型（コンパイル時最適化） のコードを比較する具体例を C++ で示します。

1. ループ内定数計算の比較
   1986年型（最適化なし）
   #include

int main() {
int x = 5;
int arr[4];

for (int i = 0; i < 4; ++i) {
    arr[i] = i * (x + 3); // x + 3 は毎回実行時に計算される
}

for (int i = 0; i < 4; ++i) {
    std::cout << arr[i] << " ";
}

}
x + 3 がループごとに計算されるため、無駄な実行時コストが発生。
2025年型（constexpr + 最適化）
#include

constexpr int factor() { return 5 + 3; } // コンパイル時に評価

int main() {
int arr[4];

for (int i = 0; i < 4; ++i) {
    arr[i] = i * factor(); // factor() はコンパイル時に 8 に置き換えられる
}

for (int i = 0; i < 4; ++i) {
    std::cout << arr[i] << " ";
}

}
factor() はコンパイル時に 8 に置き換えられ、実行時の計算が不要。
2. 関数呼び出しの比較
1986年型
#include

int square(int x) { return x * x; }

int main() {
int y = square(5); // 実行時に関数呼び出しが発生
std::cout << y;
}
2025年型（constexpr + インライン化）
#include

constexpr int square(int x) { return x * x; }

int main() {
int y = square(5); // コンパイル時に 25 に置き換えられる
std::cout << y;
}
実行時の関数呼び出しが不要になり、パフォーマンス向上。
3. 条件分岐の最適化（constexpr if）
1986年型
#include

template
void f() {
if (N > 0) {
std::cout << "Positive\n"; // 実行時に条件判定
} else {
std::cout << "Non-positive\n";
}
}

int main() {
f<5>();
}
2025年型（constexpr if）
#include

template
void f() {
if constexpr (N > 0) {
std::cout << "Positive\n"; // コンパイル時に選択される
} else {
std::cout << "Non-positive\n"; // この分岐はコンパイルに含まれない
}
}

int main() {
f<5>();
}
コンパイル時に不要分岐が削除され、分岐予測ミスや無駄な命令が発生しない。

✅ まとめ
constexpr を使うと、定数計算、関数呼び出し、条件分岐、ループ不変式などをコンパイル時に処理できるため、実行時コストが大幅に削減されます。
1986年型ではこうした最適化は手動で行う必要があり、ローコード・ノーコードでも生成コードは非効率でした。
2025年型ではコンパイラが自動で最適化し、生成コードも効率的になります。
希望であれば、これらをさらにローコード・ノーコード生成コードの文脈で「1986 vs 2025」対比表＋コード例」として整理してQiita記事用にまとめることも可能です。作りますか？
ChatGPT の回答は必ずしも正しいとは限りません。重要な情報は確認するようにしてください。

参照

ChatGPT利用の技4つ with ChatGPT
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

ChatGPTから学ぶ　３倍褒めて３分の１貶す
https://qiita.com/kaizen_nagoya/items/91e70fd8caa25076718b

AI時代の相棒は、キミに決めた！ 推しのAIエージェントをシェアしよう！企画参加まとめへの序章
https://qiita.com/kaizen_nagoya/items/e3fd7557bac97d1b88f2

記事投稿数、いいね数の目標設定して ChatGPTに聞いてみた。
https://qiita.com/kaizen_nagoya/items/019e2ad9c3e45e45854e

AI時代の相棒は、キミに決めた！ ChatGPT推し ver.0
https://qiita.com/kaizen_nagoya/items/8068a884fb2e64cd3c4f

無料ChatGPTの処理限界
https://qiita.com/kaizen_nagoya/items/84683aee26d9f4a28af0

by ChatGPT, with ChatGPT and people opinions.
https://qiita.com/kaizen_nagoya/items/57f00f9b48b25bc231e6

ChatGPTの使い方の利点と課題 by ChatGPT
https://qiita.com/kaizen_nagoya/items/0f469e473a6ed0407daa

DataRobot 風 AI agent Robotをあなたに
https://qiita.com/kaizen_nagoya/items/1ca8ca1dedefaf739d16

ChatGPTの賢い使い方
https://qiita.com/kaizen_nagoya/items/3a7e4583553543eeeeb3

ChatGPTの弱みをあなたに
https://qiita.com/kaizen_nagoya/items/3c97c63a22939e203905

ChatGPTで裸の王様
https://qiita.com/kaizen_nagoya/items/8377be38d3a763e93811

設計 仕様 制約 AI利用開発の鍵 by ChatGPT
https://qiita.com/kaizen_nagoya/items/1b9cb2f9d26308d84791

PowerPoint　筋書き(outline), 見直し(review), 見栄え加工 by ChatGPT
https://qiita.com/kaizen_nagoya/items/37bb97fc250fca37295b

逃げ回るChatGPTを追い詰めるには
https://qiita.com/kaizen_nagoya/items/cd60426e626ba05e0377

三人寄れば文珠の知恵は直交する能力前提 by ChatGPT
https://qiita.com/kaizen_nagoya/items/512e5611615e2426bb42

プログラマ３年で社長事業（未成年編） 博士論文支援追加
https://qiita.com/kaizen_nagoya/items/326452b5bf29c144c307

自殺防止手引き原稿 補足 by ChatGPT
https://qiita.com/kaizen_nagoya/items/7e459fa7edf7205c2667

しつけ(discipline) の測定視点 by ChatGPT
https://qiita.com/kaizen_nagoya/items/6b5ce03c545f7bbd8723

技術者は英語を学ぶ必要はない。英単語の羅列でいい＝プログラム。
https://qiita.com/kaizen_nagoya/items/4fc3963a21e0339fd1c9

猫中心設計から鳥中心設計へ　part2
https://qiita.com/kaizen_nagoya/items/4d7a5a33c85e0b01dc5d

プログラマ必須科目 ChatGPTにも確認
https://qiita.com/kaizen_nagoya/items/7b30d9d119792130facd

なんで音楽とプログラムの関係がうまく書けないか。
https://qiita.com/kaizen_nagoya/items/489a68d360df4b26f87d

AI利用業務手引き
https://qiita.com/kaizen_nagoya/items/f201b292f37dba16e9ef

C言語(C++)が必要な人と必要ない人
https://qiita.com/kaizen_nagoya/items/2afe9e846b55b24cb6f1

C言語(C++)が必要な人、必要ない人　ChatGPT
https://qiita.com/kaizen_nagoya/items/a074cb8cd292d8d94bd4

C言語を習得する３つの方法
https://qiita.com/kaizen_nagoya/items/84cab0888c193bba429b

C言語を習得する３つの方法　ChatGPT
https://qiita.com/kaizen_nagoya/items/4a3518a18fa49f46787f