Qiita のトレンド記事を要約してまとめたモノ（さぼり）

Posted at 2024-09-22

API教に入信しよう【REST APIの教え】

この記事は、RESTful API 設計の原則と推奨されるベストプラクティスについて説明しています。著者は、API を「美しい」と呼ぶことにより、使いやすい、変更しやすい、堅牢で、恥ずかしくない API の重要性を強調しています。

記事では、HTTP メソッドの適切な使用、エンドポイント設計のガイドライン、パラメータの渡し方、レスポンスの構造化、エラーハンドリングの重要性について詳しく解説しています。

特に、動詞を使用しないエンドポイント設計、複数形の使用、パスパラメータとクエリパラメータの使い分け、オブジェクトと配列を用いたレスポンス構造化、ステータスコードとエラー詳細の提供について具体的な例を挙げて説明しています。

この記事は、API を設計する際に考慮すべき重要な要素を網羅しており、より良い API を構築するための実践的な指針を提供しています。

私がマージンをできるだけ使いたくない理由

テックブログ記事要約

この記事は、CSSのmarginを避けるべき理由について、著者の意見を述べています。

著者は、marginが「不可解な挙動」と「コンポーネントとしての使い回し難さ」を生み出すとし、その理由を具体的に説明しています。

不可解な挙動に関しては、Margin Collapseと呼ばれる現象に注目し、縦方向に重なるマージンが相殺されることや、親エレメントを無視してマージンが適用されるケースを例に挙げています。

コンポーネントとしての使い回し難さに関しては、コンポーネント内でmarginを利用することで、デバイスの幅に合わせてレイアウトが崩れてしまう可能性や、追加の要素を追加した際に意図しないレイアウトになる可能性を指摘しています。

解決策として、パディングやflex/gridのgapを利用することで、marginよりも柔軟性のあるレイアウトを実現できると説明しています。

記事の結論は、marginは柔軟性に欠けるため、エレメント間を離したい場合は、親要素にパディングやflex/gridのgapを用いる方が望ましいということです。

要約した内容の身:

この記事は、CSSにおけるmarginの使いすぎによる問題点と、その解決策を解説しています。著者は、marginはコンポーネントの使い回しやレスポンシブデザインに悪影響を与える可能性があると主張しており、より柔軟なレイアウトを実現するために、パディングやflex/gridを活用することを推奨しています。

会社のTeamsからBedrockを呼ぼう！AWS Chatbotの新機能でコード書かずにAIボット作成

この記事は、AWS Chatbotを使って、Microsoft TeamsからAmazon Bedrockの生成AIチャットボットをノーコードで開発する方法を紹介しています。

手順は以下の通りです。

Teams環境の準備: Teamsチャネルを作成します。
Bedrockエージェントの作成: Anthropic社のClaude 3 Sonnetモデルを使って、Bedrockエージェントを作成します。
AWS Chatbotの設定: AWS ChatbotをTeamsに接続し、Bedrockエージェントにアクセスする権限を付与します。
Teamsの設定: TeamsにAWSアプリを追加し、Bedrockエージェントに接続します。

これで、TeamsからBedrockエージェントに質問し、生成AIの回答を得ることが可能になります。

この記事のポイントは、Bedrockエージェントが単なるLLMの呼び出しではなく、高度な機能を持つことです。

行動計画を生成
不明点があれば聞き返し
会話の短期/長期記憶
Lambda実行、外部API呼び出し
社内データソース参照
不適切な応答のフィルター

これらの機能を使って、より洗練されたAIチャットボットを開発することができます。

Python で作る協調フィルタリング入門：カレー推薦システム

この記事は、協調フィルタリングというAI技術を用いて、カレーの推薦システムを作る方法を解説しています。

具体的には、ユーザーのカレーに対する評価データから、類似したユーザーの評価を参考に、そのユーザーがまだ評価していないカレーの推薦スコアを算出します。

記事では、Pythonコードを用いて実際に推薦システムを実装し、新しいユーザーに対するカレーの推薦結果を可視化しています。

また、カレー店のメニュー開発やパーソナライズドメニュー、マーケティング戦略など、協調フィルタリングの様々な応用例を紹介しています。

さらに、特徴量の追加やコンテンツベースのフィルタリングとの組み合わせなど、より精度の高い推薦システムを作るための発展的な課題も提示しています。

この記事を通して、協調フィルタリングの仕組みと具体的な実装方法、そして様々な応用事例について理解することができます。

要件定義｜3分で読める非機能要件について

この記事は、システム開発における非機能要件の重要性を強調し、その中でも可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6項目について解説しています。各項目の詳細な説明に加え、顧客とのすり合わせの重要性や、非機能要求グレードを活用した効率的な検討方法も紹介されています。特に、非機能要件は顧客がイメージしづらく、運用後に課題が顕在化する可能性があるため、提案側は顧客への丁寧な説明と、潜在的な問題に対する対策を事前に提示することが重要であると結論付けています。

社長に聞きたい売上と利益

この記事は、企業の財務状況を理解する上で重要な基本的な概念である売上、費用、利益、損益分岐点について解説しています。

まず、売上は商品やサービスを販売して得た金額、費用は商品やサービスを提供するためにかかるお金、利益は売上ー費用で計算されることを説明します。

次に、費用は変動費と固定費に分類され、変動費は販売量に応じて変化する費用、固定費は販売量に関わらず発生する費用であると説明します。

損益分岐点は売上と費用が一致するポイントであり、それを超えると利益が発生し、下回ると損失が発生します。損益分岐点を計算することで、企業は事業計画を立てる上で重要な判断材料を得ることができます。

損益計算書は企業の経営成績を示す書類であり、売上高、売上原価、営業利益などの項目から企業の収益性を把握することができます。

記事は、これらの基本的な概念を理解することで企業の健康状態や将来の方向性をよりよく理解でき、ビジネス初心者でも経営判断が向上すると結論づけています。

WebAssembly を使ったサーバレス開発の基礎と実践 (ServerlessDays Tokyo 2024 配布用資料)

WebAssembly を使ったサーバレス開発の基礎と実践: 要約

この記事は、ServerlessDays Tokyo 2024 で配布された資料に基づき、WebAssembly を用いたサーバレス開発の基礎と実践について解説しています。

記事の主な内容:

WebAssembly の概要: WebAssembly の仕組みや利点、サーバレス開発における役割を説明します。
WebAssembly での開発: WebAssembly で開発を行うためのツールやライブラリ、開発環境の構築方法を解説します。
サーバレスプラットフォームへのデプロイ: AWS Lambda や Google Cloud Functions などのサーバレスプラットフォームへの WebAssembly アプリケーションのデプロイ方法を説明します。
実践的なユースケース: WebAssembly を利用した具体的なユースケースとして、画像処理や機械学習などの例を紹介します。
WebAssembly の将来展望: WebAssembly の将来展望と今後の発展について言及します。

記事の要点:

WebAssembly は、高速で安全な実行環境を提供し、サーバレス開発に最適な選択肢です。
WebAssembly を使うことで、様々な言語で記述されたコードを効率的に実行できます。
WebAssembly の活用により、サーバレスアプリケーションのパフォーマンス向上や開発効率の改善が期待できます。

記事のターゲット読者:

WebAssembly とサーバレス開発に興味がある開発者
WebAssembly を活用したアプリケーション開発を検討している開発者

この記事の価値:

WebAssembly の基礎知識とサーバレス開発への応用方法を理解できます。
WebAssembly を使った開発を始めるための具体的な手順を学ぶことができます。
WebAssembly を活用したアプリケーション開発のメリットと可能性を理解できます。

コードの綺麗さにおける２つの観点（部品と構造）

この記事は、コードの美しさについて、部品レベルと構造レベルの2つの観点から解説しています。

部品レベルの美しさは、変数や関数の命名、コードの可読性、コードの重複の排除など、コーディングの基本的なルールを守ることによって実現されます。

構造レベルの美しさは、オブジェクト指向、関数型プログラミング、デザインパターンなどの設計手法を用いることで実現され、コードの拡張性、堅牢性、テスト容易性などを向上させます。

この記事では、綺麗なコードを書くための方法として、書籍やコードを読む、他人の目に触れる機会を持つ、AIやエディタのプラグインを活用する、設計について学ぶ、実践経験を積むなどを提案しています。

要約すると、綺麗なコードを書くためには、コーディングの基本的なルールを理解し、適切な設計手法を用いることが重要であり、実践を通して経験を積むことが不可欠です。

LINEのWebhookをPostmanで再現したい

この記事は、LINEのMessaging APIを使った開発において、ローカル環境でWebhookのテストを効率的に行うための方法を解説しています。具体的には、Postmanを用いてWebhookのテスト環境を構築し、署名検証を含むリクエストを送信する方法を紹介しています。

記事では、Postmanの設定方法をステップバイステップで説明しており、以下の手順を踏みます。

コレクションの設定: Webhookのエンドポイント設定、ヘッダー設定（Content-TypeとX-Line-Signature）、ボディ設定（Webhookイベント）、スクリプト設定（署名生成とヘッダーへの追加）を行います。
環境の設定: LINE Developersから取得したチャネルシークレットを環境変数として設定します。
実行: 設定した環境でPostmanを実行することで、Webhookへのリクエストが送信され、アプリの動作確認が行えます。

この方法により、Webhook URLを公開することなく、ローカル環境で様々なテストケースを試すことが可能となり、開発効率の向上と安全な開発を促進します。

ELBテストでAZを表示させるページを作りたい！

記事要約

この記事は、EC2インスタンスの所属するAvailability Zone(AZ)を表示するページを作成する方法を紹介しています。

手順:

EC2インスタンスを作成し、ユーザーデータにHTTPサーバーのインストールとAZ情報を取得してHTMLページを作成するスクリプトを設定します。
インスタンス起動後、ブラウザでアクセスすると、所属するAZが表示されたページが表示されます。

利点:

ALBでマルチAZ構成にした場合、それぞれのAZに設置されたインスタンスのページにアクセスすることで、負荷分散の状況を確認できます。

ポイント:

ユーザーデータを用いて、インスタンス起動時に必要な処理を実行できます。
メタデータサービスを用いて、インスタンスに関する情報を取得できます。

まとめ:

この記事では、EC2インスタンスのAZ情報を表示するページを作成することで、負荷分散の状況を視覚的に確認する方法を説明しています。

TypeScriptで学ぶプログラミングの世界 Part 1[手続型からオブジェクト指向へ]

この記事は、プログラミングにおける手続型プログラミングとオブジェクト指向プログラミングの違いについて解説しています。手続型プログラミングはコンピュータに順番に指示を出す方法で、単純なプログラムには適していますが、プログラムが大きくなると管理が難しくなります。オブジェクト指向プログラミングは現実世界の物事をプログラムの中で表現する方法で、クラス、オブジェクト、インターフェース、継承などの概念を用いることで、コードをわかりやすく構造化し、管理しやすく、拡張性の高いプログラムを作ることができます。この記事では、これらの概念を日常生活の例を用いて解説しており、特にオブジェクト指向プログラミングがもたらす利点として、コードの再利用性、わかりやすい構造、新しい機能の追加のしやすさ、管理のしやすさ、現実世界の表現のしやすさ、型の安全性などを挙げています。TypeScriptはJavaScriptに型システムを追加した言語であり、オブジェクト指向プログラミングをより安全かつ効率的に行うことができるという点も説明されています。

Goで利用するORM・SQLライブラリ比較とsqlcの魅力

この記事は、Goのデータベース操作ライブラリであるsqlcの解説記事です。sqlcは、手書きのSQLから型安全なGoコードを自動生成することで、データベース操作の効率化とコードの堅牢性を両立するツールです。

記事では、sqlcの特徴を他のライブラリ（database/sql, sqlx, gorm）と比較しながら説明しています。sqlcは、SQLの柔軟性を保ちつつ型安全性を提供する点で優れており、開発速度とコードの堅牢性を両立できることが利点として挙げられています。

具体的な例として、簡単なSQLクエリからsqlcを用いてGoコードを自動生成する手順が示されています。生成されたコードは、データベース操作のためのメソッド群を含み、型安全な操作を保証しています。

記事の最後では、sqlcの使用経験に基づき、開発ツール選定の重要性と、プロダクトの価値・メンテナンス性向上のための適切な技術選定の必要性が述べられています。

AWS LambdaにおけるARM64とx86_64の性能比較

AWS LambdaにおけるARM64 (Graviton2)とx86_64のパフォーマンス比較

この記事では、AWS LambdaにおけるARM64 (Graviton2)とx86_64のパフォーマンスを、I/Oバウンド処理、CPUバウンド処理、並列処理の観点から比較した結果が示されています。

実験内容:

Pythonを用いたサンプルコードを実行し、メモリサイズごとの処理時間を測定。
メモリサイズは128MB、256MB、512MB、1024MBの4段階で設定。

結果:

I/Oバウンド処理、CPUバウンド処理、並列処理のいずれにおいても、ARM64がx86_64よりも優れたパフォーマンスを示しました。
特に、CPUバウンド処理では、浮動小数点演算の処理効率がARM64で大幅に向上していました。

考察:

ARM64 (Graviton2)は、低消費電力でありながら、I/Oや計算負荷の高い処理においても優れたパフォーマンスを発揮することが確認されました。
AWS Lambda環境において、ARM64はコスト効率の良い選択肢となりえます。

結論:

ARM64アーキテクチャは、従来のx86_64アーキテクチャと比較して、低消費電力ながら高い処理能力を実現できることが実証されました。特に、AWS Lambda環境において、コストパフォーマンスの高い選択肢となりうるでしょう。

MapReduceの使いどころを探る：データ構造と課題の関係性

この記事は、MapReduceのデータ構造と課題への適用に関する理解を深めることを目的としています。

主なポイント:

MapReduceは、データを小さな単位に分割し、並列処理して結果を集約する、データ処理の考え方です。
MapReduceは、非構造化テキストデータ、キーバリューペア、グラフデータ、時系列データなど、様々なデータ構造に適用できます。
データ構造と課題の特性を理解することで、より効果的なMapReduce設計が可能になります。
記事では、各データ構造に対応する課題の例と、Pythonを用いた実装例が紹介されています。

具体的には:

非構造化テキストデータは、ログ分析やテキストマイニングに適しています。
キーバリューペアは、ユーザー行動分析やインデックス作成に適しています。
グラフデータは、PageRank計算やコミュニティ検出に適しています。
時系列データは、移動平均計算や異常検知に適しています。

記事を通して、MapReduceの具体的な適用方法が理解でき、自分のプロジェクトでMapReduceを利用する際に役立つ情報が得られます。

OCIのBaseDBをGoogle CloudのEM Expressからクロスクラウド経由で管理する

この記事は、Google CloudからOracle Cloud Infrastructure (OCI)上のデータベース(BaseDB)を管理するために、Oracle DatabaseのWebベースの管理ツールであるEnterprise Manager Express (EM Express)を利用する方法について解説しています。

手順としては、まずBaseDBでEM Expressを有効化し、必要なポートを開放する必要があります。次に、Google Cloud側のセキュリティリストもしくはネットワークセキュリティグループ (NSG)でBaseDBへのアクセスを許可する設定を行います。

最後に、Google Cloud側のインスタンスからブラウザでBaseDBのIPアドレスとポート番号にアクセスすることで、EM Expressにログインし、データベースを管理することができます。

しかし、記事の最後では、EM Expressは19c以降サポート終了しており、23aiでは利用できないこと、また機能面でも制限があるため、管理ツールとしては適切ではないことが述べられています。そのため、今後は有料のEnterprise Manager Cloud Controlを利用することを検討していく必要があると結論付けています。

C++ で使うファイルの拡張子

C++ ファイルの拡張子に関する記事要約

この記事は、C++ ファイルの拡張子について、その歴史、慣習、そして適切な使い分けを解説しています。

要約:

C++ ソースコードには決まった拡張子は存在せず、慣習的に .cpp, .cc, .cxx などが使われます。
ヘッダファイルも同様に .h, .hpp, .hh, .hxx などが使われます。
標準ライブラリのヘッダファイルは拡張子なしで、マイクロソフトのプロジェクトではインライン関数の定義に .inl が使われることがあります。
GitHub や各種ライブラリでは、上記以外にも .c++, .h++, .ipp, .ixx, .tcc, .tpp などの拡張子も存在します。
拡張子の使い分けはチームやプロジェクトによって異なる文化が存在し、一概に正しい方法はありません。
著者のおすすめとしては、ソースコードには .cpp や .cc を、通常のヘッダファイルには .h や .hxx を、そして異常な使われ方をするヘッダファイルにはわかりやすい拡張子（チームで .hh を使うなら .hxx など）を使うことを提案しています。
テンプレートやインライン関数の定義を分ける場合も、ファイル名で明確にすることで、拡張子で区別する必要はないと主張しています。

結論:

C++ の拡張子には様々な選択肢があり、チームやプロジェクトによって使い分けが異なります。重要なのは、チーム内で統一されたルールを設け、コードの可読性と理解を促進することです。

【AWS × Terraform】ECSでエロ画像検出APIを爆速デプロイしてみた

この記事は、AWSのECSタスクにElastic IPを直接紐づけることができない問題に対する、Terraformを使った解決策を紹介しています。

従来、ECSタスクに割り当てられるIPアドレスは動的であり、S3バケットのポリシーや環境変数を都度変更する必要がありました。

しかし、Network Load Balancer (NLB) を利用することで、Elastic IPを固定し、タスクへのアクセスを安定化させることができます。

記事では、NLB、ターゲットグループ、リスナー、ECSクラスター、タスク定義、サービス、セキュリティグループの各設定をterraformを使って自動化する方法を解説しています。

これにより、UIでの手動設定や、サービス消し忘れによる不必要なコスト発生を防ぎ、効率的で安定した運用を実現できます。

プロジェクトにおける見積もり方法の種類と比較

この記事は、プロジェクト見積もりの様々な手法を紹介しています。紹介されている手法は、3点見積もり、類推見積もり、ボトムアップ見積もり、トップダウン見積もり、デルファイ法、パラメトリック見積もりの6つです。それぞれの方法の特徴、メリット、デメリット、そして具体的な利用シーンが解説されています。

3点見積もりは、楽観値、最頻値、悲観値の3つの値から期待値を算出する方法です。不確実性の高いプロジェクトに適しています。類推見積もりは、過去の類似プロジェクトのデータに基づいて見積もる方法です。短時間で概算を見積もることが可能です。ボトムアップ見積もりは、プロジェクトを細分化して見積もる方法です。詳細な設計が完了している場合に適しています。トップダウン見積もりは、プロジェクト全体の規模から概算を見積もる方法です。プロジェクト初期段階に適しています。デルファイ法は、複数の専門家の意見を聞き合わせる方法です。複雑なプロジェクトに適しています。パラメトリック見積もりは、パラメータと過去のデータに基づいて見積もる方法です。大量のデータがある場合に適しています。

記事では、これらの手法の具体的な例も紹介されています。また、WBS (Work Breakdown Structure) とガントチャートの違いについても説明しています。WBSはプロジェクトを細分化して可視化するツールであり、ボトムアップ見積もりはWBSに基づいてコストや期間を算出する方法です。

最後に、この記事では、プロジェクト管理を自分の人生にも応用できるという考え方を提示しています。

【Wordpress】カスタム投稿をカテゴリーと投稿日で絞り込む機能を自作する

この記事は、WordPressでカスタム投稿タイプ「news」のアーカイブページに、投稿日とカテゴリーで絞り込む検索機能を実装する方法を解説しています。

実装では、サブクエリに「date_query」と「tax_query」という2つの条件を設定し、検索ボタンを押下時にURLパラメータから投稿日とカテゴリーの情報を取得します。

具体的な手順は以下の通りです。

画面内の要素を整理: 投稿年月をセレクトボックス、カテゴリーをラジオボタンで表示します。
セレクトボックスの作成: 投稿タイプが「news」の投稿をサブループで取得し、投稿された年・月ごとに配列に格納します。この配列をセレクトボックスの選択肢として使用します。
ラジオボタンの作成: カスタムタクソノミー「news_category」をget_terms()関数で取得し、選択肢として表示します。
投稿の絞り込み: URLパラメータから投稿日とカテゴリーの情報を受け取り、date_queryとtax_queryを使ってクエリに条件を設定します。
投稿の表示: 条件が設定されたクエリで投稿を取得し、表示します。

実装のポイント:

サブクエリにdate_queryとtax_queryを設定することで、投稿日とカテゴリーの複合的な絞り込みを実現できます。
URLパラメータから取得した情報を用いて、クエリに条件を設定します。

前提条件:

WordPressの基本的な知識
Advanced Custom Fieldsを使用していること

この記事では、詳細なコード例と共に、実装方法を分かりやすく解説しています。

「Message from debugger: Terminated due to signal 9」エラーの原因と対応~CPU利用率・メモリ使用量改善~

個人開発アプリにおける「Message from debugger: Terminated due to signal 9」エラーの改善

この記事は、個人開発アプリのアップデート中に発生した「Message from debugger: Terminated due to signal 9」エラーの解決方法について記述しています。このエラーは、CPU使用率やメモリ使用量が高すぎるために発生します。

記事では、エラーの原因を特定し、改善するために以下の2つの方法が試されました。

LazyViewの導入: HomeView画面内のPostViewが、実際に必要になる前に作成されていたため、CPU負荷が高くなっていました。そこで、LazyViewを導入することで、PostViewがボタンクリック時にのみ作成されるようにし、CPU負荷を軽減しました。
PostModelをstructからclassに変更: structは値型であるため、データの更新時にコピーが発生し、CPU負荷とメモリ使用量が増加していました。classは参照型のため、コピーされるのはポインタのみとなり、データのコピー回数を減らすことができます。これにより、CPU負荷とメモリ使用量を大幅に削減しました。

これらの改善により、CPU利用率とメモリ使用量が改善され、アプリがクラッシュしなくなったとのことです。記事では、CPU使用量とメモリ使用量の最適化について、更なる学習を続けていくことを示唆しています。

aws-cli Athena/Lambdaのラッパースクリプトを書いて作業を効率化する

記事要約

この記事では、Amazon AthenaとAWS Lambdaの操作を効率化するためのシェルスクリプト「aws-athena」と「aws-lambda」を紹介しています。

aws-athena は、Athenaクエリの実行と結果取得を自動化するスクリプトです。コマンドラインに直接クエリを入力するか、SQLファイルを読み込むことで、クエリのステータスを監視し、結果を整形して出力します。構文エラーなどの問題が発生した場合も、エラーメッセージを表示します。

aws-lambda は、Lambda関数のリスト表示や特定の関数の呼び出しを簡略化するスクリプトです。関数名とJSON形式のペイロードを指定することで、関数を呼び出し、実行結果とレスポンスログを表示します。

これらのスクリプトにより、コンソール操作を減らし、作業効率を向上させることができます。今後の目標として、Glue JobとBatchのSubmit Job用のラッパースクリプトの開発も検討されているとのことです。

要約した内容の身

この記事は、AWSのサービスであるAthenaとLambdaの操作を効率化するためのシェルスクリプトを紹介しています。これらのスクリプトは、コマンドラインでクエリを実行したり、Lambda関数を呼び出したりする際に、コンソール操作を減らし、作業効率を向上させる効果があります。今後の開発では、Glue JobとBatchのラッパースクリプトも作成する予定とのことです。

Proxmox上でWindows Server 2022を立ち上げてみた

この記事は、Proxmox VE環境にWindows Server 2022をVMとして構築する手順を解説しています。著者は、無料試用版のWindows Server 2022 ISOイメージとVirtIOドライバーをダウンロードし、Proxmox VEでVMを作成、起動してOSインストールを行いました。インストール時に必要なVirtIOドライバーを適用することで、ストレージとネットワークが正しく認識され、VMをリモート操作するためのゲストツールもインストールしました。結果、Windows Server 2022の自由な利用環境を構築することに成功しました。

新卒が要件定義からタスクを任された話

この記事は、入社2ヶ月目の著者が、プロダクトの追加機能開発を通して得た経験をまとめたものです。

要求・要件定義編では、ユーザーストーリーを定義し、ステークホルダーとの合意形成を図り、工数を正確に見積もる重要性を学びました。
開発編では、仕様がしっかり決まっていることの重要性、QAの観点の重要性を感じました。
リリース編では、リリース前に変更内容を周知徹底することの重要性、想定外のニーズへの対応の難しさを経験しました。

著者は、この経験を通して、開発フロー全体を理解し、開発における様々な課題やその解決策を学ぶことができました。今後は、この経験を活かして、自身の開発スタイルを確立していくことを目指しています。

畳み込みニューラルネットワーク

この記事は、畳み込みニューラルネットワーク（CNN）を用いて手書き数字の画像認識を行う方法について解説しています。

まず、MNISTデータセットを用いて、8枚のフィルターを持つシンプルなCNNモデルを作成します。入力画像にフィルターを適用し、その出力を全結合層に繋げ、最終的に10個の出力層ニューロンで数字を分類します。

次に、このモデルを学習させ、テストデータで評価を行います。その結果、96個のテストデータのうち誤認はわずか2つとなり、高い精度で数字を認識できることが示されました。

さらに、学習によって得られた8枚のフィルターの可視化も行い、各フィルターが特定の特徴を抽出している様子が確認されました。

このコード例を通して、CNNが画像の特徴を効率的に抽出し、分類問題に高い精度で適用できることが示されています。

【第2弾】O1-Previewに自作東工大模試を解かせてみた【プロンプト変更】

この記事は、東工大作問サークルの創設者であるソリング氏が、自作の東工大模試を最新の言語モデルであるO1-Previewに解かせた結果を報告しています。前回はプロンプトの指示が曖昧だったため、今回は「高校範囲」という縛りを明確にし、解答過程も記述するようにプロンプトを修正しました。

記事では、O1-Previewが解答した大問1から大問5までの解答と採点結果が掲載されています。全体的に、O1-Previewは問題を理解し、適切な解答を導き出すことができていますが、一部、高校範囲外の知識や誤った計算が見られます。特に、大問2ではコインの枚数の増減を漸化式で近似しようとしていますが、その方法が間違っています。大問5では、二項係数の性質に関する問題で、Legendreの公式を正しく適用していますが、一部条件を満たす範囲が曖昧な記述が見られます。

全体として、O1-Previewは数学の問題を解く能力がある一方で、まだ人間の解答者と比較すると精度や論理的な思考に課題が見られます。今後の発展が期待されます。