全般

『誰も知らない超優良企業』（渡部清二）を読んだことをきっかけに、バリュー株に興味を持つようになりました。 バリュー株とは、企業の本来の価値や資産、利益に対して株価が割安であり、今後、業績の改善や市場評価の見直しによって株価の上昇が期待できる銘柄のことです。 私も、そうしたバリュー株を見つけて実際に投資してみたいと思うようになりました。 続きはQiitaの投稿記事を参考願います。 https://qiita.com/ogi_kimura/items/c8bb72e2c790fb5f961a

仕様には「一般的仕様」と「固有仕様」があり、さらに固有仕様の中には「表出的仕様」と「暗黙的仕様」があります。 　このうち特に厄介なのが暗黙的仕様です。 暗黙的仕様は文書化されておらず、現場の慣習や担当者の経験に埋め込まれているため、表に出して明文化するだけでも大きなコストと時間がかかります。 モダナイゼーションが難しいのは、単に古い技術を新しい技術に置き換えるからではありません。 「何を再現すべきか」が分からないからです。 だからこそ重要なのは、現行システムを丸ごと再現することではなく、業務の本質を見極めたうえで、何を残し、何を捨てるかを決めることです。 言い換えると、モダナイゼーションの成否は「暗黙的仕様をどれだけうまく扱えるか」に大きく左右されます。 　その延長線上にあ るもう一つの論点、すなわち現行仕様の複雑度について考えます。 続きはQiitaの投稿記事を参考願います。 https://qiita.com/ogi_kimura/items/0684f95269a381caf91d

DX推進に必要な要素として 3つの知識領域 と 3つの仕様領域 があり、とりわけ 「暗黙的仕様」（現場が言語化できていない／していない固有の仕様）をどう扱うかで、DXの進め方が大きく変わります。 進め方（案）は大きく3つあり、いずれにもメリット・デメリットがあります。 ただし現実のDX推進では、コストや期間、人員といったリソースに制約があり、理想に対して「どこかで割り切る」判断が必要になります。つまり、各案のトレードオフを踏まえて案を選定することになります。 今回は、前回の 知識×仕様（3×3）のマトリクス を、時間軸（=理解・合意形成に要する時間） も含めて捉え直し、どのように進めるのが現実的かを整理します。 続きはQiitaの投稿記事を参考願います。 https://qiita.com/ogi_kimura/items/8fe4af4b4fa1b4497315

会社として「DXを進める」と声高に言っている一方で、上層部がそれを自分事として捉えず、部下や担当者に対して叱咤だけが飛んでいる――そのような状況をよく目にします。 私自身、現場に入り込んでプロジェクトの動きを見てきましたが、うまくいかない理由は「担当者の知識不足」といった単純な話ではないと感じています。 一方、米国などではトップダウンが強く、かつ経営層がITの知識をある程度持っているケースも多いため、相対的にシステム変革が進みやすい印象があります（もちろん例外はあります）。 私はいくつものDX案件に関わる中で、「なぜうまくいかないのか」を考える機会が増えました。昔は「情シス部が先頭を切って推進しなければならない」という空気があり、弱い立場になりがちな情シス部がドメイン知識を十分に持たないままデスマーチに巻き込まれていくこともありました。事業部側はそれをどこか他人事のように見てしまう、という構図もあったように思います。 一方で現在は、「事業部こそが先頭を切って推進しなければならない」という風潮に日本全体が寄っています。しかしその結果、ITリテラシー

管理職って、本来は意思決定や改善に時間を使いたいはずなのに、現実はルーチンワークが多いです。私の場合、月初に「承認のハンコを押す」「請求書PDFをダウンロードする」「Web画面の金額と税額を目で突き合わせる」といった作業が発生します。 しかもシステムが遅く、60件程度の承認をするだけで概ね1時間。正直、この時間を“確認のための確認”に使うより、もっと価値のある仕事に回したい。そこで、このルーチンワークを自動、もしくは半自動で処理できる仕組みを作ろうと考えました。 続きは、Qiitaの投稿記事を参照ください。 https://qiita.com/ogi_kimura/items/4a0e58ac0a9399e06b00

どうしてもPineconeのRAGを使って、インタラクティブアバターを作りたいと思っていました。副業でお客様と相談して、今回はHeyGenの知識ベース（デフォルト）を使うことにしましたが、今後知識が増えると、それでは対応しきれなくなります。やはりRAGによる実現が必要だと考えていました。しかし、6ヶ月間いろいろな資料を調べましたが、なかなかうまくいきませんでした。そして今日（2026年1月2日）、ついに動作するようになったので、ソースコードを紹介します。これが皆様のプログラミング意欲の向上につながれば幸いです。 Qiitaに記事を投稿していますので、詳細はこちらをご覧ください。 https://qiita.com/ogi_kimura/items/20f6a4c176bc1ebe91a2

この予約処理は毎月1回、月初の深夜0:00に実行する必要があります。現在の状態では、私のPCでしか動作しないため、毎月深夜に立ち会って処理を実行する必要があります。しかし、私自身は仕事の都合で月初の営業日は早朝出勤が必要です。このままだと、深夜に娘の予約対応を行い、そのまま早朝から仕事に向かうという、非常にハードなスケジュールをこなさなければなりません。 そこで、娘のPC（Windows）でも予約処理が自動的に動作するように「exe化」を行うことにしました。さらに、exe化により頻繁なソースコードの変更が難しくなることを考慮し、現在はソースコード内に直接記載している「月日」の設定を「csvファイル」に外部出力して管理することにしました。

今回は、seleniumを活用してWebブラウザを操作する方法について解説します。先日、大学に通う娘から「サークルでWebブラウザを使って予約をしなければならないが、これを自動化できないか？」と相談を受けました。 これまでにseleniumに関する記事をいくつか投稿してきましたが、まだ十分に自信がありませんでした。とはいえ、娘からの依頼ということもあり、改めてseleniumを深く学び、Webブラウザ操作を本格的に扱えるようになろうと決意しました。 この記事では、Webブラウザの操作を自動化して予約処理を実現する方法を紹介し、作成したソースコードも公開しています。 詳細は、以下のURLからご確認願います。 https://qiita.com/ogi_kimura/items/4ec8c7c29b0669426276

前回の投稿記事ではDifyの「ワークフロー」を用いて、firercrawlにてスクレイピングを簡単に実施する方法を紹介しました。 今回は、Difyの「ワークフロー」を用いて、画像生成を行うサービスStablediffusionにて、簡単画像生成に挑戦してみたいと思います。 一連のDifyの「ワークフロー」をマスターすれば、Difyを使っていろいろな処理が簡単に出来るようになると思います。 詳しくは以下のURLをご確認ください。 https://qiita.com/ogi_kimura/items/6f6449885063d98827ff

前回、Difyを使用してFirecrawlの結果を「ナレッジ」に登録し、それを基にLLMで要約を行うワークフローを作成しました（これを「ナレッジを登録する方法」と呼びます）。 今回は、Firecrawlの機能を直接使用してスクレイピングを行う方法（以下、「直接Firecrawlを使ってスクレイピングする方法」と呼びます）に挑戦します。今回もノーコードで実施します！ 詳細は以下のURLからご確認ください。 https://qiita.com/ogi_kimura/items/447b2244b32392091159

前回の記事では、Firecrawlを使用したプログラミングをPythonで実装し、Webブラウザのコンテンツをテキストファイルに出力する方法を試してみました。 今回の記事では、Difyのワークフローを活用し、プログラミングをせずに結果を表示させる方法に挑戦します。これまでの投稿では、ローカルLLMであるOllamaをDifyに接続してチャットを試したことがありますが、ワークフローの作成は今回が初めてです。どれほど簡単に実現できるのかを検証してみます。 詳細は以下のURLからご確認ください。 https://qiita.com/ogi_kimura/items/63389dddd6c9f6b63717

前回と前々回は、browser-useに関する記事を投稿し、AIが自律的にWebブラウザを使ってコンテンツ情報を取得する仕組みについて解説しました。今回は、Webブラウザを介さずに「スクレイピング」という手法でコンテンツ情報を取得するツール、Firecrawlを試してみます。 ただし、「スクレイピング」は誤った使い方をすると他のWebサイトに迷惑をかけたり、トラブルを引き起こす可能性があります。そのため、ご自身が管理しているWebサイトや利用許可を得たサイトでのみ実施するようにしてください。 それでは、Firecrawlを使ったスクレイピングに挑戦してみましょう！ 詳しい内容は、以下の投稿記事をご覧ください。 https://qiita.com/ogi_kimura/items/5800af71691737848c92

seleniumとbrowser-useを活用することで、Webサイト上の豊富で最新な情報をより効率的に自動取得できる可能性があると考えています。 今回は、このbrowser-useエンジンを活用して、チャット形式でのやり取りを実現できないかと模索しました。 その手段として、streamlitを使用したプロトタイプの構築に挑戦しています。 具体的には、チャット形式での使用感や性能（レスポンス時間など）の確認を目的としています。 詳細は、以下の投稿記事をご覧ください。 https://qiita.com/ogi_kimura/items/f0834e5b357a8d6c9d11

MBA取得に向けた小論文や面接の準備に追われていたため、ここしばらく記事を書く時間がありませんでした。しかし、会社が冬期休暇に入り、少し余裕ができたので、久しぶりに記事を書いてみることにしました。 最近、browser-useというPythonライブラリが登場したことを、Google検索などで知りました。以前、seleniumを使ったWebブラウザ操作の自動化に関する記事を投稿しましたが、このbrowser-useはよりインタラクティブな操作が可能で、将来的な可能性を大いに感じています。 今回は、このbrowser-useを使ったプログラミングに挑戦し、その使い勝手や将来性について確認してみたいと思います。 詳しくは、以下の投稿記事をご覧ください。 https://qiita.com/ogi_kimura/items/2bff25e43ecbfed1a624

先日、 YOLO を使用して10ファイルほどの画像を元にアノテーションファイルを作成し、自分で「重み付けファイル」を生成しました。その後、「学習」「検証」、そして最終的に「検出」を実施しましたが、期待していたような結果を得ることができませんでした。その主な原因として、...

冒頭のカレンダーですが、私はほぼ毎日ジョギングをしており、その履歴を紙のカレンダーに記録しています。「走」はジョギングをした日を表し、その横に記載している数字は体重です。「飲」は夜にお酒を飲んだこと、「筋」は筋トレをしたこと、「外」は外食をしたことをそれぞれ示しています。外食をした翌日は、たいてい体重が増えてしまいます💦 このように紙のカレンダーに記録しているものの、体重の増減をグラフで視覚的に確認したくなりました。そこで、毎日Webシステムに体重を登録し、それをグラフで表示できるような仕組みを作りたいと考えるようになりました。 そんなときにReplitの記事を目にし、「これならWebシステムが作れるのでは？」と思い立ちました。そこから（約20分ほど）奮闘した記録をこの記事にまとめてみました！ 詳しくはQiitaの記事をご覧ください https://qiita.com/ogi_kimura/items/835e020a15d169e57d48

皆さん、突然ですが「このコップ、水が入っているのかな？」と考えたことはありませんか？私はといえば、家にいるときや作業中、ふと目の前のコップを見て「水が入っているか、空なのか」が気になることがあります。そして、あるときQiitaの記事を読んでいて思いつきました。...

現在の職場では、私は軽量なモバイルPCを持ち歩き、打ち合わせなどに参加しています。モバイルPCは持ち運びに便利な反面、ディスプレイが小さく、複数のウィンドウを開くと画面がすぐにいっぱいになり、ウィンドウが重なることも多々あります。 　会社ではこの点を配慮し、デスクには大きな外部ディスプレイを設置しています。そのため、デスクで作業するときには、2画面で作業ができ、効率も数倍向上するとの話を書籍で目にしたこともあり、とても快適に仕事を進められています。 　一方で、打ち合わせなどでモバイルPCを持ち歩く際には1画面に戻るため、ウィンドウの位置やサイズが毎回変わってしまいます。私は日常的に約20個のウィンドウを開いているため、再びデスクに戻った際はそれらをチマチマ元の位置に戻す作業が発生します。1日に10回程度画面の切り替えがあるので、1回あたり3分かかるこの作業により、1日で約30分、1か月で10時間、年間で120時間の無駄が生じている計算になります。 　この状況を改善すれば、年間に換算して一人月のコスト削減が見込まれます。そこで、情報システム担当とし

最近、**Qiita**に投稿される記事を見ていると、「**Dify**」という単語をよく目にするようになりました。記事の内容から、自分のPC上で**ChatGPT**のような「チャットボット」を簡単に作成できるツールのようだと感じたため、今回は**Dify**の構築方法や操作感について確認してみることにしました。 詳しくはQiitaの記事をご覧ください https://qiita.com/ogi_kimura/items/d13631b3a77e18023ef9

システム開発者であれば、一度は「システム関連図」を自動化できないかと考えたことがあるはずです。私も、過去の投稿記事でPDFや画像認識を使って自動生成できないか試みましたが、精度や汎用性に限界を感じました。最終的に、Excelのシェープ（円や四角）を利用して関連性を基づき作図する方法に行き着きました。結果としては十分な精度が得られたものの、シェープ同士の関係性を手作業で定義するのは非常に手間がかかり、現実的ではありません。 一方で、システム開発者として、もう一つ気になるのが「プログラム構造」です。例えば、「この関数に引数を追加したらどの部分に影響が出るのか？」や、「メソッド名を変更した際、どれだけの箇所を修正する必要があるのか？」といった悩みは、日常的に直面する問題です。もちろん、grepなどの検索ツールもありますが、それだけでは不十分だということを多くの技術者は痛感しているでしょう。 そこで今回は、「システム関連図」の代わりに「プログラム構造解析」に焦点を当て、Neo4jとgpt-4oを使ったPythonプログラムを作成してみようと思います。ここ